Minimal CP-M SBC design

[Allison]

>
>Subject: Re: RE: Minimal CP-M SBC design
>   From: "Chuck Guzis" <cclist at sydex.com>
>   Date: Fri, 09 May 2008 09:36:31 -0700
>     To: cctalk at classiccmp.org
>
>> Date: Thu, 08 May 2008 07:50:46 -0400
>> From: Allison 
>
>> I can make the boot process easier as you can plop the rom in 
>> mappable space.   The usual arguement is can you get a Z180
>> in a package most people are willing to deal with (64pin dip)?
>
>I wouldn't want to deal with the DIP as it's a "skinny" DIP with 
>0.050 pin spacing, unlike, say, the 68K.  While it probably makes 
>little difference on a PCB, it requires an adapter if you're 
>prototyping--and sockets are hard to find.  It's easier to use the 68 
>pin PLCC to keep the spacing--smaller footprint too.

Cant argue with that but many are put off by that and discard 
playing with Z180.

>> The latter is the shadow rom many have refered to.  I usualy do that.
>> And make the rom BIG so not only can I map it in when I want but also
>> access part of it  (ROMDRIVE).
>
>I believe the Amstrad Joyce uses the printer controller to force the 
>necessary boot code onto the Z80 bus.  (Tony?)  At least I've never 
>seen a boot ROM on a Joyce PCB.  

Ther are a lot of way s to stuff in code, the real trick is doing
with few parts as wirewrapping or other build strategies are labor 
intensive and "kitting with a board" is cost sensitive.

>> There is no requriement to boot the system from "disk"
>> and making that change can make bring up simpler.
>
>But that's where the "authentic" aspect fails me.   Why run a 
>"vintage" CP/M system without the experience a disk drive gives you?
>You'll be deprived of the "BDOS Err on B:" messages.  What fun is 
>that?

Do a A>:ASM BIGFIL.AAB and forget the disk in B: and you remember 
why you hate that.

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?

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.

But what about 68000 or Z8000 runing CP/M they exist too?  The 
problem there being they are file system compatable but neither 
can ran any of the vast library of CP/M 80 code base.

>One might as well run an emulation program on a PeeCee.  I wouldn't 
>be at all surpised to find that someone's done it for the iPod Touch--
>there already exists a NEC 9801 emulator for that platform.   

I'd argue that CP/M on an iPOD is not close to a useful experince.
For one without a keyboard the interaction is via GUI that could 
never have existed back when on anything Z80.  That falls into 
cool hack catagory right up there with using a WRT54GL as a 
wireless web server.

There are many emulators the classic ones and some really useful
ones too.  I'd argue for playing with aps a SIM on PC is valid 
enough.  I'd also for hacking hardware a sim on PC is bogus. I 
never figured out a way to simulate a board of random logic to
emulate a process control card adn plug that into a sim complete 
with simulated stimulus.  For me and I may be atypical I use both.
I use the PC with MyZ80 or Daveid Dunfields N*Horizon and of 
course SIMH as software test platforms and even as portable 
CP/M when I've forgotten to bring my PX-8.  But I also use 
those SIMs to build real platforms with 8085 or Z80.  And there 
is a different feel, real or perceived, to running on real iron 
even if the iron is a 10mhz Z80 with 64k of ram and 512kb of ram 
disk and 32mb of CF or my NS* Horizon built in '78 with a 32mb 
hard disk, 5.25" floppy and 8" floppy.

>From a modern perspective, regardless of the hardware used be it 
CF or a SA800 programming the BIOS is a mystery or stopper for 
many as for all the people out there writing code few ever get 
that close to the metal.  That makes the real iron a challange.


>> Deblocking is not too mysterious.  The real missing bit in the 
>> Alteraion guide is how the BDOS telegraphs the need to preread 
>> and when to skip it.  
>
>Page 14, section 12 entitled "Sector Blocking and Deblocking" in the 
>Alteration Guide covers it pretty well.  I remember being relieved to 
>find the information after I struggled with 1.4 not having any such 
>mechanism.  I don't think it was in 2.0 either, but I can check if 
>anyone's curious.
>

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.

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.


Allison


>Cheers,
>Chuck