Manufacturing new S-100 prototype boards

[NobodyIsHere]

Hi,

I am working on a S-100 kit building project and am looking for prototype and/or wirewrap boards to implement some S-100 cards. I am fairly certain I will need at least three boards to get a full up working S-100 system; one Z80 CPU, one memory, and one serial IO. I could probably get the the memory onto a single board with the CPU but the purpose is to test out the whole system so two cards is an absolute minimum. However, it leaves none available for the rest of the project which is to bridge my ECBbus project onto S-100.

With a bit of luck, I have obtained two different prototype/wirewrap boards of unknown condition. (Thanks Terry!) So far, I have found it difficult to obtain additional S-100 prototype/wirewrap boards. I have seen them (rarely) on Ebay and there is at least one manufacturer of S-100 prototype boards.

http://www.vectorelect.com/Product/Plugbord/PBSTDBUS.htm

Vector Electronics has a number of distributors including the common ones like Digikey, Mouser, Newark, etc

http://www.vectorelect.com/Distributors.htm

The big drawback on the Vector Electronics is the board cost is rather steep at $50-$60 a piece. Maybe this is the best route but I am exploring alternatives right now.

One idea I am considering is to just have an existing prototype board scanned and replicated similar to how the AltairKit people did it. I am sure this is not cheap either but once the initial order is placed I assume subsequent boards runs would be much cheaper.

http://altairkit.com/creation_of_a_kit_story.html

Does anyone have any ideas on how to proceed or experience in having a PCB replicated? How do other S-100 kit builders deal with this? Do you just build your own PCBs from scratch? Am I missing something?

I certainly am interested in your thoughts on the subject.

Thanks!

Andrew Lynch

 

[Terry Yager]

Just a suggestion, the serial port hardware will use the least real estate, and therefore is a more likely candidate for doubling-up on one of the other boards (assuming you do end up with some extra space).

--T

 

[Terry Yager]

I forgot to ask, how are you going about your prototyping? If you're wire-wrapping, perhaps you could get by with just a perf board cut to the right size, and an edge connector salvaged from another (presumably dead) board. Might not be pretty but...

--T

 

[NobodyIsHere]

I forgot to ask, how are you going about your prototyping?

Hi,

So far all of my prototyping on the Test Prototype (ECBbus based Z80) is based on generic protoboards using point to point wiring with soldered connections. Due to the scarcity of S-100 prototype boards, however, I am strongly considering moving to wirewrap to reduce stress on the protoboard.

I am also considering just taking the leap to building my own PCBs. If I cannot get a source of cheap prototype boards, I think what I will do is wire up a simple Z80 S-100 CPU/SRAM board on one prototype board and a serial UART only on the other. Then make a PCB replacement for the relatively less complex serial design. Hopefully, proof out my PCB technique with it the more simple board and repeat the process for the CPU/SRAM board.

However, the discussion about making Z80 CPU boards and replacing them with custom PCBs is a major undertaking. It has taken me months to build the Test Prototype using prototype boards so this project is going to take quite a while to do if it is practical at all.

With cheap prototype boards, I just solder the connections since I believe they tend to be more reliable and durable assuming the soldering joint is done right. However, it does result in the "fuzz ball" prototype with wires usually on both sides of the board. PCBs would fix that problem but at the expense of a lot more time invested. All that soldering though basically makes the prototype boards "consumables" since once they are used, their is no practical recovery or reuse possible. With S-100 prototype boards, that does not appear practical.

If you're wire-wrapping, perhaps you could get by with just a perf board cut to the right size, and an edge connector salvaged from another (presumably dead) board. Might not be pretty but...

--T

Yes, I have considered just fabricating my own prototype board. Getting the perf board is no problem as Jameco and others have them of large enough size.

The problem lies in the edge connector. I have yet to find a 100 pin male edge connector component which would mate to the female S-100 bus connector.

If anyone knows where to get some, please speak up! If I could find dead S-100 boards, I would either repair them or scrap them and mount a mezzanine perf board on top of it using nylon standoffs.

What I need is the S-100 equivalent of this:

http://s.guillard.free.fr/Apple2IDE/proto-top.jpg

See the blue green plastic male edge connector on the protoboard? I could find some of those in 100 pin S-100 compatible format, I'd be home free. I could build S-100 prototype boards all I wanted.

Experience tells me when I find myself in one of these quandries, it is usually because I am overlooking something obvious. I am hoping someone will be so kind as to point it out! Take me to school!



Thanks!

Andrew Lynch

 

[NobodyIsHere]

Just a suggestion, the serial port hardware will use the least real estate, and therefore is a more likely candidate for doubling-up on one of the other boards (assuming you do end up with some extra space).

--T

Yes, I agree. I think the serial UART portion will not take up a lot of board space since all it needs is an IO address decoder (74LS32, 74LS14), 16650 UART, line driver (MAX 232) with capacitors, 1.8432 MHz local clock, and connector space. I am thinking like 5 or 6 sockets and a connector with a bunch of wiring plus the local rectifier/heatsink circuit. However, a simple serial board also makes for a nice discrete component for PCB initial building and S-100 bus check out.

My Test Prototype core CPU board contains a Z80, clock, 32K EEPROM, 512K x 8 SRAM, memory pager circuit, IO decoding logic with configuration latch, reset and interrupt switches, and about 6 idiot LEDs in a 100 x 130 mm protoboard.

The core IO board contains PPI, UART, RTC circuit, bus control logic, bus transceivers, and on the bus connector on another 100 x 130 mm mezzanine board with 2" standoffs. Basically, it is a dual board "sandwich" design which forms a neat little box that plugs into the end of the ECBbus passive backplane.

However, one of the major goals of the S-100 kit building is to proof out the working motherboard, PS, etc so I need at least two boards to verify those systems are working.

I am fairly sure that since the S-100 provides 5.3" x 10" size even after subtracting out the local rectifier and heatsink will have about 1.5 to 2 times the working area of my existing protoboards. Of course, that is before I have actually done it so take it with a grain of salt.



Thanks!

Andrew Lynch

 

[Terry Yager]

I'll send you another ready-made board that you can use (temporarilly), if it'll speed things up a little. The one I have is a dual-serial/game port/RTC, but the serial port is a simple 8250 UART/1488/1489 design for each port, which, along with a couple other small chips, takes up very little space. You could perhaps copy the design & layout for your own board. Either way, borrow mine for as long as you need, so you can put off doing your own until the bitter end, when you'll have a better idea of how much board space is available. I believe the whole thing could be implemented in ~3" x 3" or so.

--T

 

[NobodyIsHere]

OK, Thanks! I think I will take you up on that offer but it will be a few weeks until I wrap up some of these other things currently on the workbench.

It is going to be a while before the S-100 board building begins as I have some rebuilding to do on the Chassis and motherboard. I will be reforming the power supply this weekend. I am not sure how long it will take to completely fix up the box but it will be 2 - 3 weeks or so.

In addition, last night I got the IDE interface working on the Test Prototype. At least, now the hard disk responds correctly to a "Get ID" command so I am fairly sure the hardware is mostly working. Now its more testing and writing the software to read and write sectors, edit the partition table, format the partitions, etc. Fortunately, using Linux cfdisk speeds up the hard disk manipulation a lot.

It is the CP/M CBIOS extensions which are going to be the challenge. Fortunately, I already have a working Test Prototype CBIOS so it will mostly be just extending it and I can use some other examples as guides like the one for GIDE, etc.

After the IDE interface wraps up, I plan on implementing an FDC circuit and then a video board. Neither of those are trivial but they'll have to wait until I get the IDE hard disk working so I have a decent development environment in place. Then I start the Test Prototype S-100 bridge board project.

Thanks!

Andrew Lynch

 

[Thrashbarg]

I had a write up for making your own PCB's in the general off topic section but it seems to have disappeared.

There are heaps of pages on Google about the method, http://www.google.com/search?q=etching+PCB+boards+glossy+paper

I've found that rather than cooling off the board and trying to dissolve the paper under water it's easier to slowly peel off the paper with the iron heating it. At least that way if you notice a broken trace you can put the paper back and try again.

I've successfully made a 120x300mm backplane board using this method. S-100 cards should be fine.

Double sided boards are a bit more tricky because you have to get the traces aligned. I've read one method is to draw a cross hair in the CAD program on both layers, then drill through the board on one side at the cross then align the other side with the drill bit.

Also, do you want a copy of my CBIOS I made for my 8080 computer? It may help you make yours. The disk controller is a WD1772 and UARTS are 8251's. It implements the IOBYTE.

 

[NobodyIsHere]

I had a write up for making your own PCB's in the general off topic section but it seems to have disappeared.

There are heaps of pages on Google about the method, http://www.google.com/search?q=etching+PCB+boards+glossy+paper

I've found that rather than cooling off the board and trying to dissolve the paper under water it's easier to slowly peel off the paper with the iron heating it. At least that way if you notice a broken trace you can put the paper back and try again.

I've successfully made a 120x300mm backplane board using this method. S-100 cards should be fine.

Double sided boards are a bit more tricky because you have to get the traces aligned. I've read one method is to draw a cross hair in the CAD program on both layers, then drill through the board on one side at the cross then align the other side with the drill bit.

Thanks for the links Thrashbarg,

Unless I am missing something, making my own PCBs for the S-100 kit building project seems like the way to go. Like a lot of projects, I will start small with some toy examples and work up to an S-100 board.

In the meantime, I'll be refurbishing the Chassis, power supply, and motherboard. I think I can build a Z-80 CPU/SRAM board based on some existing schematics as a guide. The serial port probably would make a good first case for a do it yourself PCB project.

Also, do you want a copy of my CBIOS I made for my 8080 computer? It may help you make yours. The disk controller is a WD1772 and UARTS are 8251's. It implements the IOBYTE.

Sure! Thanks! I am interested in looking over CBIOS code for ideas on how to fix/improve my own code. I can post the Test Prototype CBIOS if you'd like. It does not support IOBYTE (yet) as there is really only console serial IO presently. Also, there are two drives, a 22K ROM drive and a 448K RAM drive. The next big push as part of the IDE interface project will be to extend the CBIOS to support IDE hard disk partitions.

Last night I did more experimentation on Test Prototype IDE interface. The good news is the sector read and write routines seem to be working fine after a little tweaking. The funny thing is the hard disk was formatted with Win98 and the sectors are apparently written in little endian byte order which makes sense in retrospect but caught me a bit off guard.

My example code for the "IDENTIFY DEVICE" ($EC) IDE controller command retrieves the IDE drive meta-data which is partially human readable and big endian formatted. The code retrieves the meta-data and it looks fine in the debugger but when I apply the same code to read a sector like the MBR, the data comes back all flipped. You can still read it and tell what it is supposed to be but its obvious something is wrong. To fix it I made two separate read routines, one with big endian for getting the IDE meta-data and another with little endian for reading/writing sectors.

If the IDE hard disk were a pure CP/M only drive the partition table is basically irrelevant and none of this would matter as you could just hard code the parameters into the CBIOS routines. Then you can write bytes in any order you like as long as you consistently read them the same way.

However, I would like to preserve the partition table compatibility with the defacto IBM PC format standard as much as possible. The existing partition table gives great information like the LBA starting sector number for all the partitions which in theory should make writing the CBIOS a bit easier and more portable. Also, I can use existing tools like Linux cfdisk to create the partition table rather than rewriting those functions from scratch. Writing the formatter function in CP/M is fairly straight forward but parsing through the partition table looks like a PITA.

I think your CBIOS will be most interesting in the FDC area as once I finish the IDE interface it is my next project for Test Prototype. I am still debating whether to go with WD2797 or i8272(765A)/9229 FDC route. I think WD2797 is a better FDC but i8272 are more common and schematics and code examples are readily available.

You wouldn't happen to have a schematic of your FDC circuit would you? Are you using an onchip data separator or a stand alone chip? Those data separators are a real bear to find these days which makes the WD2797 more appealing.

Have a great day! Thanks!

Andrew Lynch

 

[Thrashbarg]

http://kaput.homeunix.org/downloads/cbios.asm

The 8080 is only *just* fast enough to keep up with FM formatted disks. I don't know about the Z80 but considering it's usually run at 4MHz rather than 2MHz it should work with MFM disks without a DMA controller. Just make sure interrupts are disabled.

The code's a bit of a mess, but it works.

 

[NobodyIsHere]

http://kaput.homeunix.org/downloads/cbios.asm

The 8080 is only *just* fast enough to keep up with FM formatted disks. I don't know about the Z80 but considering it's usually run at 4MHz rather than 2MHz it should work with MFM disks without a DMA controller. Just make sure interrupts are disabled.

The code's a bit of a mess, but it works.

Thrashbarg, Wow! Cool! Its a thing of beauty!

Your 8080 Mk II is like my Test Prototypes Australian cousin or something. The design similarities are amazing. I use the Radio Shack prototype boards and the 96 pin DIN 41612 connector for the bus.

Thanks for posting, I am going back to look over your website some more.

Andrew Lynch

PS, a working CBIOS is a working CBIOS. A little messiness just adds character. ;-)

Once things work, I tend to leave them alone unless there is some compelling reason to make the change. Otherwise its just too easy for those nasty unintended bugs to creep in.

 

[NobodyIsHere]

http://kaput.homeunix.org/downloads/cbios.asm

The 8080 is only *just* fast enough to keep up with FM formatted disks. I don't know about the Z80 but considering it's usually run at 4MHz rather than 2MHz it should work with MFM disks without a DMA controller. Just make sure interrupts are disabled.

The code's a bit of a mess, but it works.

Thrashbarg,

I just looked over your FDC schematic. Nice, but no picture of the Mk II FDC card :-( PLEASE POST!

I see you are using the i8272 with the digitial PLL data separator replacement circuit. Is it based on the Sinclair +3 FDC design?

Did you program your own 74S188? You must have since getting one pre-programmed is pretty darn tough. I have a circuit design (untested) which replaces the 74S188 with a multiplexer and an adder if you are interested. Also I found a 74S188/82S83 PROM programming circuit (also untested). Those little PROMs are in several "vintage" designs so I think it will come in handy eventually.

BTW, sweet case! It just gave an idea for an old desktop ATX case I have in the basement.

I do not see an IDE interface board for the Mk II, are you interested in a little IDE interface project collaboration? Building one from off the shelf 74LSxxx parts is not very hard. I can post part lists, pictures, schematics, sample test and CBIOS code, etc whatever you like. I know it works somewhat already. It's a disgusting mess right now but, hey, two hands make short work! Think about it, OK?

Thanks!

Andrew Lynch

 

[Thrashbarg]

The description for the FDC controller is "FDC concept based on the 765 FDC, used in PC's. I'm now using a WD1772 from an old Atari ST", so, no, I'm not using a 8272. I tried, but I couldn't get it working. I'm going to try it again with my next computer project (probably 68008 based using the STEbus) because I don't want to have to keep swapping the WD1772 between the new project if/when it's finished and the 8080.

Yes it's based on the 3+ FDC. In fact I'd go as far as saying it IS the 3+ FDC.

I had thought about a hard drive, but I had gotten the floppy disks working with CP/M and decided to leave it at that. I'll be using the NCR SCSI controller from a dead Mac Plus for the next project for hard disk storage, and possibly Minix, which is why I was asking about the source code in another thread.

I'll draw you up a schematic for my WD1772 ASAP.

In the mean time here's the schematic I based it on.
http://www.6502.org/users/andre/csa/shug/csashug.png

Andre's 6502 project is excellent by the way . Notice the DMA and IRQ signals are attached to the 6522 so they can be read in software, I did the same with mine except using a 74LS244 buffer.

Also, the drive enable signals are attached directly to the 6522, mine are attached to a 74LS175 hex flip-flop (or was it 74LS174...). My CBIOS code is such that the drives are only enabled when data access is happening, this causes the lights on the floppy drives to flicker. Not very good when the drives have a head load system. Mine don't.

Hope this gives you some clues until I can draw the schematic.

 

[NobodyIsHere]

The description for the FDC controller is "FDC concept based on the 765 FDC, used in PC's. I'm now using a WD1772 from an old Atari ST", so, no, I'm not using a 8272. I tried, but I couldn't get it working. I'm going to try it again with my next computer project (probably 68008 based using the STEbus) because I don't want to have to keep swapping the WD1772 between the new project if/when it's finished and the 8080.

Sorry, I missed the description. I was looking at the schematic itself. Actually, this is a bit disturbing as I thought the intel 8272 was a licensed clone of the NEC 765 and as such should perform identically. Is that not so?

:eh:

Duh. I just went and re-reviewed your CBIOS listing. I must be particularily dense this morning. For some reason I had mental lock you were using a 765/8272 FDC even though you said you were now using a WD1772. OK, so forget the whole 765/8272 issue as it is not related to the Mk II. Hopefully the coffee will kick in soon...

As a side note, when you were working on the 765/8272 based design were you able to burn the program into the 74S188 PROM? What did you use if so? I have found trying to get a 74S188/82S83 PROM burner is very tough.

I am still trying to make up my mind on whether to go WD2797 or i8272 for the FDC. However, if I do go with the i8272, I am using an offboard data separator chip as I found a couple of the little beasties. They are pretty scarce too.

Yes it's based on the 3+ FDC. In fact I'd go as far as saying it IS the 3+ FDC.

Cool. I thought it looked familiar.

I had thought about a hard drive, but I had gotten the floppy disks working with CP/M and decided to leave it at that. I'll be using the NCR SCSI controller from a dead Mac Plus for the next project for hard disk storage, and possibly Minix, which is why I was asking about the source code in another thread.

Aw C'mon, you know the Mk II wants a shiny new IDE HD -- just think how much faster Zork will load!

The basic design is from Hans Summers CPCNG project:

http://www.hanssummers.com/computers/cpcng/ide/index.htm

You can't get much simpler a CP/M hard disk than the IDE interface using LBA. I made mine with off the shelf 74LSxxx chips (no PALs, GALs, PROMs, or other funky programmable chips)

2 74LS373 8 bit latches
1 74LS245 8 bit bus transceiver
2 74LS32 quad OR 2 input gates
1 74LS14 hex inverter w/schmidtt trigger
2 74LS27 tri 3 input NOR gates

1 40 pin header connector
1 96 PIN DIN 41612 bus connector

Lots of wires but not too many.

The design has 3 configuration resistors which I ended up disabling as I think they caused the IDE HD to not respond (?). I sent an email to Hans Summers to try to figure out what was going on with the circuit. It either it has a design flaw or maybe I screwed something up. No matter, it works now.

I can manipulate the IDE registers directly through the IDE port (which starts at IO address $20) using my monitor which is pretty cool.

The test software is a variation of the demonstration software found here with minor tweaks to account for subtle changes in the circuit:

http://www.retroleum.co.uk/z80-ideinterface.html

Last night while starting modifications to my CBIOS, I realized that while my CP/M TPA is 62K (CBIOS starts at $F200, I think) I had placed my Monitor at $F800. "Free space" I was thinking...

Oops. Big mistake since there is little room for expansion of the CBIOS code. I am going to have to rearrange the boot loader and memory map to allow some additional CBIOS room. I had been meaning to make the Monitor a regular loadable CP/M program anyways but here is the reason to finally do it.

I'll draw you up a schematic for my WD1772 ASAP.

In the mean time here's the schematic I based it on.
http://www.6502.org/users/andre/csa/shug/csashug.png

Andre's 6502 project is excellent by the way . Notice the DMA and IRQ signals are attached to the 6522 so they can be read in software, I did the same with mine except using a 74LS244 buffer.

Cool! Thanks!

Agree on Andre Fachat's stuff. He is awesome indeed. Not too mention he has a whole series of pages of stuff related to CRTCs which is another area of interest for me. I would like to make a video card based on the SY6545 (IO port access vs shared memory like MC6845) for Test Prototype. I have a circuit I just cannot wait to implement but I have to finish the IDE HD and FDC peripherals first.

Also, the drive enable signals are attached directly to the 6522, mine are attached to a 74LS175 hex flip-flop (or was it 74LS174...). My CBIOS code is such that the drives are only enabled when data access is happening, this causes the lights on the floppy drives to flicker. Not very good when the drives have a head load system. Mine don't.

Hope this gives you some clues until I can draw the schematic.

Thanks! Best of luck on the new homebuilt!

Andrew Lynch

 

[Terry Yager]

Last night while starting modifications to my CBIOS, I realized that while my CP/M TPA is 62K (CBIOS starts at $F200, I think) I had placed my Monitor at $F800. "Free space" I was thinking...

IIRC, there is no free space at the top of CP/M. You expand your BIOS by moving it's base downward, along with BDOS & CCP, shrinking the size ot the TPA.

Oops. Big mistake since there is little room for expansion of the CBIOS code. I am going to have to rearrange the boot loader and memory map to allow some additional CBIOS room. I had been meaning to make the Monitor a regular loadable CP/M program anyways but here is the reason to finally do it.

Wouldn't it be more gooder to put the monitor on a ROM that can be switched in/out for troubleshooting? Doesn't do much good as a transient if your CP/M isn't booting. (Or am I misunderstanding your use of the term 'monitor')? Your boot-loader could also be in bank-switched ROM to leave more memory available for CP/M.

--T

 

[NobodyIsHere]

Terry,

Yes, there is not supposed to be free space at the top of CP/M. It is an artifact of the original Test Prototype memory map. Originally, the monitor started out in ROM in the low regions $0100 - $0800 or so. Then I made it a "ROM free" design by copying the monitor to RAM and switching out the ROM. $F800 seemed like a logical place at the time. Later I added CP/M and just left the monitor in place and the machine still boots directly into the monitor. From there I can manually start CP/M if I want or just use the monitor depending on what I need at the time.

The monitor is still in ROM but it is meant to run at $F800 (its position specific code) and is copied to its final location in RAM before the ROM is switched out. Basically, the new approach will be to let the CCP+BDOS+CBIOS expand from $F200 or so on up to $FFFF. Then make a program on the ROM drive which can put the monitor at a new RAM location like $E000 when it is needed. I wanted to push the ROMs out of the memory map and have a CP/M friendly all RAM design. The boot loader is already ROM only and switches out with some other routines on successful boot. It only comes back into memory when the ROM drive portion is accessed.

With the new changes, if CP/M fails to boot, I will have troubles because there is no monitor to fall back on. However, CP/M boots from a ROM drive by nearly the same method as the monitor and it has been fairly reliable so far. If CP/M won't come up most likely the monitor wouldn't either. Just in case, I am keeping a back up copy of the current EEPROM set aside so if the CP/M image does go bad, I can force the monitor back in with just an EEPROM change.

Thanks!

Andrew Lynch

 

[Thrashbarg]

Heh, that's exactly how I did it. My original monitor was at 0F800h too, until it got so big I had to move it to 0F000h (monitors v1 and v2 respectively).

What I did to get around the initial problem of choosing between CP/M and the boot monitor, when I got CP/M going, was to have the boot ROM read the toggle switches on the front panel, if they were non-zero then load the monitor (straight from ROM), otherwise boot into CP/M. The monitor only had two commands, load hex and jump. It was enough to upload debugging hex files until I got CP/M going properly. This was monitor v3.

Then I decided to have fig-FORTH 1.1 in ROM, so I made a word called BOOT to load and jump to the first sector of the first floppy drive, which would then load CP/M. This is how the 8080 operates as of now. It's useful having both systems to play with.

http://www.worldofspectrum.org/BackToThePlus3/prommer.html is what I used to program the PROM's. I think I bought three and screwed up the first two. I've got two 8-pin data separators now (UM8326) so I'll use them should I use a 765 again.

 

[NobodyIsHere]

Err... I just reviewed this thread and it has wandered a bit off topic. All good stuff but lets not incur the wrath of the moderators.

So, back to S-100 board manufacturing. I have contacted a few potential prototype board manufacturers inquiring about their ability to produce/create S-100 prototype cards. So far, maybe a couple of nibbles but no solid responses yet.

If anyone knows of a manufacturer of PCBs, maybe a small local company or one run by a fellow vintage enthusiast who would be willing to undertake a limited run of S-100 prototype boards, now would be a good time to speak up or contact them.

If anyone knows S-100 prototyping alternatives to commercial boards that would be good information.

Thanks!

Andrew Lynch

 

[NobodyIsHere]

Heh, that's exactly how I did it. My original monitor was at 0F800h too, until it got so big I had to move it to 0F000h (monitors v1 and v2 respectively).

What I did to get around the initial problem of choosing between CP/M and the boot monitor, when I got CP/M going, was to have the boot ROM read the toggle switches on the front panel, if they were non-zero then load the monitor (straight from ROM), otherwise boot into CP/M. The monitor only had two commands, load hex and jump. It was enough to upload debugging hex files until I got CP/M going properly. This was monitor v3.

Then I decided to have fig-FORTH 1.1 in ROM, so I made a word called BOOT to load and jump to the first sector of the first floppy drive, which would then load CP/M. This is how the 8080 operates as of now. It's useful having both systems to play with.

http://www.worldofspectrum.org/BackToThePlus3/prommer.html is what I used to program the PROM's. I think I bought three and screwed up the first two. I've got two 8-pin data separators now (UM8326) so I'll use them should I use a 765 again.

I swear Test Prototype and the Mk II are like cousins or something. That URL for the 74LS188 PROM burner kit is exactly the one I was going to suggest and plan to use myself. Nice to hear it worked for you!

So picking $F800 to place the monitor is just a confluence of design? I think it is the logical place for a small monitor. It is rather funny to see us going down such similar paths making these systems and learning the same lessons. I wonder if how common this is?

Thanks!

Andrew Lynch

 

[NobodyIsHere]

IIRC, there is no free space at the top of CP/M. You expand your BIOS by moving it's base downward, along with BDOS & CCP, shrinking the size ot the TPA.



Wouldn't it be more gooder to put the monitor on a ROM that can be switched in/out for troubleshooting? Doesn't do much good as a transient if your CP/M isn't booting. (Or am I misunderstanding your use of the term 'monitor')? Your boot-loader could also be in bank-switched ROM to leave more memory available for CP/M.

--T

Terry,
I thought about what you wrote on the Monitor and CP/M and decided against moving the Monitor. Instead I am going to assemble a new CCP+BDOS+CBIOS from source at 60K TPA and just leave the Monitor alone.

Everytime I boot Test Prototype, I run the monitor. Only about half of the time I boot up, I run CP/M so in terms of debugging the Monitor is much more useful. Also, moving the Monitor is a lot more disruptive to all the other software whereas CP/M is eventually going to have to move anyway so I might as well start now.

Thanks for the ideas! Good thinking!

Andrew Lynch