Minimal CP-M SBC design

[Allison]

>
>Subject: RE: Minimal CP-M SBC design
>   From: "Chuck Guzis" <cclist at sydex.com>
>   Date: Sun, 11 May 2008 10:24:57 -0700
>     To: cctalk at classiccmp.org
>
>> Date: Sat, 10 May 2008 08:26:41 -0400
>> From: Allison 
>
> 
>> Do a A>:ASM BIGFIL.AAB and forget the disk in B: and you remember 
>> why you hate that.
>
>Or doing "ASM BIGFIL.ASM" or even just "ASM".  I got into the habit 
>of using M80/L80 as soon as I got my hands on a copy.  DRI assemblers 
>(even RMAC) weren't any great shucks.
>
>> But then I wa an early adptor of hard disk and from late '80 on
>> had at least a 5mb drive to avoid that.  Is that less authentic?
>> By the end of 1981 I'd built a system with romdisk and ramdisk
>> and no floppy or har disk.  Was that authentic?
>
>I think I failed to make my point well enough.  Almost all the people 
>who worked with CP/M initially did so in the context of floppy disks. 
>Someone attempting to duplicate that experience would get a less-than-
>authentic experience without that aspect, in much the same way one 
>would be deprived of the experience of big mainframe iron without the 
>machine room noise level.  Could you get a true experience of running 
>OS/360 without a card reader?  An authentic experience consists of 
>all aspects of the experience, not just the convenient or pleasant 
>ones.  Without the whole, one gets a "dude ranch" picture.

For the latter without the card reader you couls substitute the tape
or even first floppy based job feeds.

As to CP/M if you want the pain oops wrong disk grab an old PC and 
dont use hard disk with DOS.  IT's somthing that one likes to 
forget quickly.

Floppies and CP/M the major issues were lack of space, not enough drives
and some cases systems that could crunch (on power off or power fail)
media left in drive (data lost).  Authentic yes, get as much done NO.
Every ones had to learn those fast and after that it was part fo the 
psyche and largely forgotten save for lack of space and not enough dives.


>> What is authentic?  To me if the platform has 8080, 8085,
>> Z80, Z180/64180, Z280, or NSC800 it's running on real iron.  Of
>> course if you have a Z380 or eZ80 in native mode or a NEC V20 
>> in 8080 mode those may count too.
>
>No, one gets extra bugs with a V20 that the 8080 never had.


;) but they are Authentic.

>> 1.4 really didn't even do a DISK bios, it was embedded in the bdos.
>> the bios for 1.4 was only terminal, punch reader and printer IO.
>> Yes, it ws a pain to interface any new disk to it.
>
>Not according to my archives.  While it's true that the 1.4 BIOS 
>lacked the configurability  of 2.0/2.2 (i.e. there were no DPBs, etc. 
>to define your own disk format), it contained the disk access code 
>(e.g. SELDSK, SETTRK, etc.)  If you'd like, I can send you a copy of 
>the CBIOS that came with my Tarbell controller, complete with 
>Processor Technology video board driver (which I didn't use).  It's 
>remarkable in one aspect--it allows for simulated 2-drive operation 
>on one drive by prompting for the A:  or B: floppy when required.
>

I have 1.4 for 8" and NS* Horizon (still running!) and their 
respective manuals.  Your right I forgot that NS* created a 
second level bios strictly for the terminal, printer, punch, reader
part of the interface.  That part if the ihterface is very lightly 
doumented in my Alteration Guide.


>CP/M 1.4 had the right idea--it supported only one diskette format, 
>so if you had more than 250K of storage, you were pretty much forced 
>to accommodate this by simulating multiple floppy drives. (Wasn't 
>there an early system that used an IMI "shoebox" drive for the Apple 
>II that simulated about 50 floppies?)  Where things got out of hand 
>is when DRI said "Roll your own" with no guidance as to disk format 
>standards.
>
>> It is in 2.0 (deblocking).  However their explanation is thin and 
>> some of the fine details have to be infered by really reading the 
>> code. It was very mysterious when I did it for the first time back 
>> in '80 when I was working with a early sample 765 DD FDC.  It was 
>> later that Andy Johnson-Laird wrote The Programmers CP/M Handbook 
>> which covers the subject in much greater detail and has two BIOS 
>> exammples that are very commented.
>
>It's been years since I've chatted with Andy.  My acquaintance with 
>him began after his book, however and I hadn't even realized that 
>he'd done anything with CP/M.
>

I'd say he write "the book" that explains things from both the 
bios/systems perspective and the applicatiosn programmers eye view.
It's the book I refer everyone too after the Alteration Guide has
confused, narrowed and limited their view of what can be done.

I've always maintained that CP/M was a UI and filesystem mostly 
and there was little it prevents and mostly allowed anything.
It did a far job of hardware abstraction and mostly kept out 
of the way.


Allison


>Cheers,
>Chuck