test-drb April 2007

test-drb@ccmp.vtda.org

257 participants
560 discussions

by ajp166＠bellatlantic.net

> >Subject: Re: Junkbox CP/M system? > From: "Chuck Guzis" <cclist at sydex.com> > Date: Tue, 24 Apr 2007 11:07:20 -0700 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On 24 Apr 2007 at 10:12, Allison wrote: > >> At a minimum. FDC interfaces are more involved as the interface has to >> include data and drive interfaces unless one can find a chip like 2793 >> or 37C65. > >My personal favorite is the WD1770/1772 series. It doesn't do >500Kbps drives (no big deal for CP/M); interface logic is very >minimal. Very simple to program; a 4MHz Z80 should be able to keep >up with the data transfer without breaking a sweat. And it fits in a >reasonably small (28 pin) DIP package. > >But a minimal system might incorporate nothing more than a PIIO or >SIO and simply pass mass-storage requests and console I/O over the >same path to a PC using a formatted message scheme. Makes the CBIOS >coding a walk in the park. If the system is 32k eprom with shadow, 1770/72 SIO, CTC and 64k of ram it's called a AmproLB. ;) Great little system on a board. the LB+ adds a 5830 SCSI interface and that makes SCSI hard disk possible. >Or, one could build the Z80 onto a PC prototype board with its own >local memory as a coprocessor and conduct mass storage and console >I/O over a pair of I/O ports. For many, that may be the best of all >worlds as it relieves one of the problem of terminal and disk >interfacing, power supply and enclosure. Of course, the folks who >want to put their project into a mahogany case with glass front may >not be taken with this idea. :) That would be identical to the DecmateII (and III) CP/M APU board. the board is a Z80, 64k of ram and two ports. The DECmate does disk and display work for it. The Z80 APU for the PRO350/380 is similar. It's been done more than once on the ISA bus (PC). As to the wood and glass case. Anything fits inside that! ;) Allison

17 years, 2 months

Hand-rolling a CP/M machine

by zmerch-cctalk＠30below.com

Rumor has it that Ethan Dicks may have mentioned these words: >On 4/24/07, Allison <ajp166 at bellatlantic.net> wrote: >>One other thing.. CPUs.. >> >>I've only mentioned Z80s.... > >>8085 (Also makes for simple systems) > >Those are somewhat common if you hang around DEC equipment. Or early Tandy laptops... ;-) >>Z180 >>Z280 >>ez80 (in Z80 mode) > >These all look like Z80 descendents to me - I'd probably rarely, if >ever, run across one to harvest. Harvest, shmarvest - Mouser/Digikey carries 'em in stock - wanna 33Mhz Z80 compatible, with access to MMU & whatnot if you choose? $13. Just like everything else computerwise, slower is cheaper... Laterz, Roger "Merch" Merchberger -- Roger "Merch" Merchberger | A new truth in advertising slogan SysAdmin, Iceberg Computers | for MicroSoft: "We're not the oxy... zmerch at 30below.com | ...in oxymoron!"

17 years, 2 months

Dayton (cctalk Digest, Vol 44, Issue 69)

by wdg3rd＠comcast.net

This message has been processed by Symantec's AntiVirus Technology. Unknown00000000.data was not scanned for viruses because too many nested levels of files were found. For more information on antivirus tips and technology, visit http://ses.symantec.com/

17 years, 2 months

Ferranti Argus 700 parts

by jim＠g1jbg.co.uk

I know of an Argus 700 that has been scrapped. Does anyone need any parts? (no processor cards - they've gone to keep another one going). Please contact me off list Jim. Please see our website: www.g1jbg.co.uk

17 years, 2 months

Hand-rolling a CP/M machine

by ajp166＠bellatlantic.net

> >Subject: Re: Hand-rolling a CP/M machine > From: "Chuck Guzis" <cclist at sydex.com> > Date: Tue, 24 Apr 2007 09:35:02 -0700 > To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at classiccmp.org> > >On 24 Apr 2007 at 12:01, Ethan Dicks wrote: > >> Right. That much I get... so once CP/M is running, it's ordinary not >> to refer to the boot ROMs? There's typically not a requirement to >> keep some low-level BIOSy stuff in ROM? > >Nope. CP/M installations are typically self-contained, though there >are a few systems that keep ROM around for I/O servicing. Since >you'll be writing your own boot code, you can do ROM mapping however >you'd like. A simple way is to keep your boot code and monitor at >0000 and have the boot routine from diskette simply unmap the ROM. >Note that the CBIOS code (which not only provides I/O, but also loads >the rest of the operating system is located in high memory and >doesn't require anything in low memory to get going. True, most (traditional) CP/M system load the whole show in high ram and rom is either in the way or turned off. Non-traditional CP/M approach: rom (and ram) if paged in and out can be a way to park code for the BIOS to keep it out of main ram area. Also non-traditional is putting the entire CP/M+ bios image in Eprom rather than on Disk or floppy system tracks. >One caution here. If you need interrupt service (say, if you're >interfacing a PC keyboard), do not give in to the temptation to use >the Z80 NMI line. NMI vectors to 0066H, which happens to be right in >the middle of FCB2. There are some very messy workarounds for this >for some systems, but the best thing to do is to avoid it. Use a >"regular" interrupt if you need one. I've seen more than a few get bitten by that beastie. My favorite is use mode 2 (Z80 vectord) by adding a LS244 to the bus that is activated by MI/*IRQ/ (interupt ack) to push in a fixed vector or just 00h. In that mode the IV (interrupt vector) register supplies the high byte making it easy to put interrupt routines at the beginning of any 256byte page in ram. >I think that the old Tarbell disk controller used a 82S23 bipolar ROM >to read one sector from disk. That's only 32 bytes, but it was >enough. Just enough! Allison

17 years, 2 months

Another unknown computer panel (is a 2870 panel)

by aek＠bitsavers.org

I located the FE manual for the 2870 in the CHM archives, and it appears to match. I'll get scans of that and the 2860 manuals up in the next couple of days.

17 years, 2 months

Quick survey on equipment

by ajp166＠bellatlantic.net

> >Subject: Re: Quick survey on equipment > From: ard at p850ug1.demon.co.uk (Tony Duell) > Date: Mon, 23 Apr 2007 23:30:04 +0100 (BST) > To: cctalk at classiccmp.org > >> > The problem was that CP/M needs RAM starting at location 0, the >> >TRS-80 has the BASIC ROMs there and starts RAM at, IIRC, 0x4000. >> >> Hmm, same problem as the Model III then (ISTR that had its ROM located at >> $0000 too, hence the reason for the Model IV). > >Exactly. The Model 1 and Model 3 are actually quite similar machines >internally, to the extent that a Model 3 ROM set will run on a Model 1 >(if sutiably addressed). Admittedly the Model 3 makes more use of the Z80 >I/O ports (almost all I/O on the M1 is memory-mapped for some unknwon >reason), but the memory nap, video, etc, are the same. Maybe because the IO instructions are slow compared to something like (8080 neumonics) Mov M,A. Also since they used a Memory mapped video that ate 1k of space along with the 12k of rom why not do the keyboard that way. Actually there are quite a few IO mapped ports on the M1 but the keyboard and Video are in the memory map. Allison > >The M4 has quite a few changes over the M3. It has the >software-selectable memory maps, allowing RAM at location 0 for CP/M. And >a much improvded video section with a 6845 CRTC chip (and not a >fixed-configuration row of TTL of the older 2 machines) thus giving am 80 >column text display, etc. > >> >....The second solution was an add-on circuit board.... >> >> Hmm, sounds like these are probably going to be as easy to get hold of now >> as hen's teeth...? > >I don't recall there being any published schematics for them either, so >if you want to build one you'll have to design it yourself. > >> >> Think I'll just get a Z80 Second Processor for my Beeb instead (far less >> hassle). > >I didn't think those were _that_ common... > >-tony

17 years, 2 months

Junkbox CP/M system?

by ajp166＠bellatlantic.net

> >Subject: Re: Junkbox CP/M system? > From: Holger Veit <holger.veit at iais.fraunhofer.de> > Date: Tue, 24 Apr 2007 15:35:10 +0200 > To: General Discussion: On-Topic Posts Only <cctech at classiccmp.org> > >Allison schrieb: >>> On CF, IOCS16- is honored--but it's not on any IDE hard drive you're >>> going to buy today. >>> >> >> I've heard that was true of any drive over 500mb and have not seen anything >> over 80mb that does. >> >> Me I keep saying if you really need the simplicity of 8b transfers and >> the low cost that comes from a surplus IDE drive just ignore the high 8bits >> and enjoy it. There's no harm from that. So what if half the storage >> is unused, likely the drive is large anyway. >> >You are going to lose the error flags from the status register which a >transferred on D8-15, IIRC. >Also the drive identify command will return only half of the data. >It is not an issue with pure data blocks; you'll then just have 256 byte >blocks rather than 512. Both are minor issues. CP/M cannot use the identify and a bios that uses it to configure is going to grow far to fast. The error bits are a minor problem, sufficient to say if you get an error (low 8bits signal generic error) whats one to do? Answer, not much as something big happened. CP/M doesn't handle errors the bios does. It's simplistic but 99.999% of the time unless there's a programming error where the host and drive are out if sync, errors mean it's time for a new drive. Allison > >-- >Holger >

17 years, 2 months

My X programs [was Dreaming of a lean installation method [was Re: *nix on]]

by mouse＠Rodents.Montreal.QC.CA

Back on 2007-04-11, people asked me about my X software. At the time the FTP area was..rather insufficiently populated. I wrote > I clearly need to push a lot more stuff to the FTP area. Probably > won't happen until after work today, though. I finally got around to this. ftp.rodents.montreal.qc.ca:/mouse/X/ is a bit more populated now. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

17 years, 2 months

Junkbox CP/M system?

by ajp166＠bellatlantic.net

> >Subject: Re: Junkbox CP/M system? > From: Holger Veit <holger.veit at iais.fraunhofer.de> > Date: Tue, 24 Apr 2007 10:04:49 +0200 > To: General Discussion: On-Topic Posts Only <cctech at classiccmp.org> >>>>snippage of lCD stuff (worthy of its own topic)>>>>>. > >You might infact look for embedded systems with a Z180 or better Z280 >CPU (PLCC84) they have most of the stuff like MMU and DMA already built >in which one needs to make a system with more than 64k. There are >already SRAMs with 128kByte >available, so no longer needs to build complex DRAM refresh schemes. SRAMS to 512k are current. Reality for CP/M applications is that none I know of use more than the base 60K(max!). So any extra ram interfaced either ends up as ramdisk or buffer space for BIOS. >>> Just buffer some data and address lines off for a floppy or IDE >> > interface >> >> From a programming point of view, how easy is accessing IDE compared >> to a typical FDC ('765 or similar)? I did write some assembler to >> access an IDE drive about 12 years ago, but have long since forgotten >> details! :-) >Effectively, the software logic is the same. You have some registers >where you put in head/track/sector information, wait for >some ready status flag and read the data out or feed a block of data in. >Differences exist between the layout of the registers, but are actually >no stumbling block for any Z80 programmer. FDC has one differce from IDE, it is not buffered and if there is no DMA the cpu does PIO and it has to do it fast. So the programming has to be a bit more carefully crafted to grab a byte every 16uS. IDE is buffered so you have all day to transfer the data. >IDE is a little bit more comfortable as you don't have to deal with >low-level disk formatting and bad-block handling. Blocking/beblocking to >convert between 128 byte sectors and 512 byte disk sectors is still >required, unless you leave this to CP/M+ (CP/M 2.2 IIRC didn't have this >directly). OTOH, one could program an FDC to use 128 byte blocks on disk CP/MV2.x does not do deblocking for you but it does provide the software flags and hooks to do it and the code is supplied (on line and in the Alteration Guide). >easily; which then will cause trouble with data exchange to a PC, >however. OTTH, the logic for an FDC is typically more complex than for >an IDE interface, usually because of some monoflop-based data separator, >including some adjustment of resistors/capacitors. At a minimum. FDC interfaces are more involved as the interface has to include data and drive interfaces unless one can find a chip like 2793 or 37C65. >From a practical standpoint I advise people building CP/M systems the following. Don't bother with floppy, it's a complex system and you have many things(including the drive) that may have to be debugged. The idea of using floppy to transfer to PC is quaint and practical but most PCs also have serial lines and that is both easier to do and if done right fast enough, plus it's portable to PC systems that don't have floppy at all. I do suggest Flash or EEprom as ROmdisk and even ramdisk using static ram as one way to have storage but IDE is a viable and generally cheap way to go. IDE drives are easily tested (any old PC can do that) and drive under 1G are usually found in both good condition and near free(or cheap). A good base CP/M system: 1 Z80 (any speed) 2 61256 (64k ram) 1 27256(or28256) 32k eprom (startup) 1 CTC or 8253 (baud clock) 1 Z80 SIO or DART (two serial channels) about 12pcs TTL glue (maybe less) 1 IDE drive This can be hand wired (wirewrap or point to point) and with that few parts it will be small. Parts are available no SMT or unobtainium. Can be done using scrap and salvage. All parts will be through hole. Performance will be good if the Z80 is 4mhz or faster. With a 4mhz Z80 and IDE drive of at least 8mb useable space it will perform as well or better than most S100 and SBC systems discussed. With a 8mhz z80 it will be fast. It will run all the CP/M software and with a larger disk (say 40mb usable or larger) you can download extensive amounts of software to the hard disk. If done right the 32k Eprom can hold a debug monitor, hard disk formatter and also an image of CP/M (with room to spare) so that startup is eased. > >Personally, I tend to use CF<->IDE adapters and build the common three >circuit TTL-IDE interface. I do not have CF is my junkbox(yet). I do have a boatload of old but known good IDE drives. Once I got over my personal dislike for wasting half the drive and stopped using D8-15 the interface is both simple and qualifies as "junkbox". Allison

17 years, 2 months

← Newer
1
...
11
12
13
14
15
16
17
...
56
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb April 2007