Interested in a home brew Z80 computer project?

[NobodyIsHere]

Hi All,

Last night I trimmed the PCB so the DIN 41612 ECB connector now fits. Also prepared the parallel port connector. Tonight I solder them in and that should complete the build phase for the first prototype SBC. Overall, it has gone pretty well and better than I expected.

The software has been bundled up and placed on the website for your review. All it really needs is to be unzipped into your TASM301 directory and it should build with the buildTP2.bat file. If not, please let me know. Probably the adjustments will be trivial though. It is not exactly the same configuration as mine as I tried to make it more general and remove the specific directories from the batch file. The rest is the same.

Respinning the new PCB is proving to be a bit more complicated. I replaced the video card in the machine in the basement with a new NVIDIA card I got from Ebay. That really has no effect on the optimiser running but at least I can stand to watch the screen. The temporary fix video card used 1024 x 768 *interlaced* mode. It was flickering terribly! It was truly awful and a trip back to the "bad old days" of early SVGA graphics. Ugh, how did we even stand that stuff? In addition, the PCB optimizer runs really slowly on the machine. It is a 2.6GHz Northwood Celeron (P4 class) with 400MHz FSB and 128K cache running Linux and the Sun Java package.

I think what I am going to do is check out Ebay to see if I can get a replacement CPU for this machine. I'll bet a 3.0 or 3.2 GHz P4 with 1MB cache would at least double the optimizers speed. At the rate this is going, even after shipping a new CPU would reduce the time this thing needs.

Please let me know if anyone has questions. I'll do my best to answer them or find someone who can. Thanks and have a nice day!

Andrew Lynch

 

[ziloo]

Hello Andrew,

... ENTIRELY IN 8080 MNEUMONICS (SO ASM CAN BE USED)
; BUT ASSUMES A Z80! ....

1- I see a mixture of ASM programs in both 8080 and Z80 instruction sets in your
ZIP file. Would you please explain about this?

2- I have heard so much about IOBYTE in CP/M; would you please give an explanation
about what it is all about...

Thank you

ziloo

 

[NobodyIsHere]

Hello Andrew,



1- I see a mixture of ASM programs in both 8080 and Z80 instruction sets in your
ZIP file. Would you please explain about this?

2- I have heard so much about IOBYTE in CP/M; would you please give an explanation
about what it is all about...

Thank you

ziloo

Hi!

Uhhh. Yeah. Not one of my proudest moments, that's for sure.

Actually, it is an artifact of trying to convert the entire code base to allow compiling on the Test Prototype target itself using the standard CP/M toolset (ASM). I tried to restrict myself to just the 8080 mnemonics but occasionally a Z80 op code was necessary for some reason or other. In those cases, I basically forced the assembler to put in the proper op code even if it didn't recognize the mnemonic. The exact technique is one I learned from Allison. For example:

LDIR1: .DB $ED,$B0 ; Z80 "LDIR" INSTRUCTION (REMOVE)

Of course, there is no 8080 equivalent to LDIR and I needed it for some block transfers in loader-a and the CBIOS. I suppose I should just convert it all back to Z80 and just accept the Z80 as a requirement but "true" CP/M portable applications are written using only the 8080 instructions. There are a few exceptions to the rule.

My goal was to remove all the Z80 peculiar instructions and have "pure" 8080 only instructions but that got to be increasingly difficult and when other problems developed, I pushed the project to the back burner. There are 8080 only equivalent subroutines and macros to help Z80 -> 8080 conversion and some of those are in the source, I think.

Some files in the ZIP file are all Z80 mnemonic and others are 8080. You can tell which is which by reading the buildTP2.bat file and which TASM commands require -85 (for intel 8085) and those for -80 (for zilog Z80).

My hope for publicly posting the Test Prototype project online, warts and all, is to keep the information from being lost entirely. It is possible that when/if people start making these SBCs for themselves that some of this code will get better testing and maybe even cleaned up a bit. Certainly there are many hours of work needed.

Regarding the IOBYTE; in essence that is a tool where the CP/M CBIOS allows some IO abstraction and redirection. The IOBYTE allows switching between CP/M devices such as CON:, PUN:, LST:, PRN:, etc with minimumal impact to the CBIOS. The Andrew Laird "Programmer's Guide to CP/M" does a great job explaining what and how this works. It was my intention to support IOBYTE in the CBIOS but again, it got sidetracked. My CBIOS does not support IOBYTE in its present form.

You'll find there are a great many rabbit trails to follow in the source code. Some actually go someplace and others just trail off into the weeds. Like I said, the test prototype software surely isn't the prettiest thing you'll ever read but it more or less works.

You remembered to have your aspirin and glass of water ready before you started reading it, right?

Thanks and have a nice day!

Andrew Lynch

PS, Check out the silliness in the dbgmon-e source. It was originally for an SBC-200 and "adapted" for new use on the Test Prototype. It is rather ghastly and even includes boot code for FDC1793 disk controller. The only problem with that is the actual disk IO board uses the NEC765 FDC.

Originally, I was going to use a WD2797 FDC chip but later changed my mind. I even have a WD2797 still sitting here just waiting for a PCB to put it in.

 

[ziloo]

Hi Andrew,

Do I understand correctly then that:

1- TASM takes the 8080/8085 code and assembles it into a form that is
executable on a Z80 CPU?

2- Probably most vintage computers with Z80 CPU were using CP/M versions
written entirely for 8080 CPU?

ziloo

 

[NobodyIsHere]

Hi Andrew,

Do I understand correctly then that:

1- TASM takes the 8080/8085 code and assembles it into a form that is
executable on a Z80 CPU?

2- Probably most vintage computers with Z80 CPU were using CP/M versions
written entirely for 8080 CPU?

ziloo

Hi!

Yes, TASM is a Table Assembler and is able to cross assemble for many targets including 8080, 8085, and Z80. Not that TASM can translate assembler mnemonics between CPUs though but the Z80 and 8085 have backwards compatible opcodes with the 8080 so it sort of appears like it.

The Zilog Z80 is opcode compatible with 8080. Zilog published a new set of assembler mnemonics for Z80 very different than the Intel 8080 mnemonics but the resulting machine language is a backwards compatible superset of the Intel 8080 opcodes.

The confusion arrises because Zilog came up with a new mnemonic format which was improved over the much older Intel mnemonic format. A lot of assemblers support one or the other and sometimes both. TASM supports both Intel and Zilog mnemonics and has rather conveniently facilitates my bad habit of switching randomly between the formats.

The Intel 8085 is essentially the same as the 8080 except for a couple of new instructions (not supported on Z80) and uses identical mnemonics.

CP/M was originally written on an 8080 and all the documentation are Intel 8080 specific. I believe all the CP/M tools are in Intel mnemonic format as well. The 8085 and Z80 both run 8080 opcodes and are both far more common CPUs. As a result most CP/M machines are not 8080 but use the Z80or 8085 instead. I am pretty sure the majority of CP/M computers are Z80 though.

There are some CP/M applications which use Z80 specific opcodes like Borland Turbo Pascal but they are very few. I cannot think of another example of Z80 dependent CP/M code except for possibly some CBIOS versions.

Here is great site to sort through the wreckage of old CBIOSs. I have gotten some really great ideas sifting through these:

http://www.speakeasy.org/~rzh/bb.html

Actually there are not all that many 8080 machines left due to their early technology and unusual voltage requirements. The Z80 machines are far more common. Intel 8085 is also very popular but more so in industrial embedded applications than in microcomputer because the chip set is specially designed for easy integration and low part count. You can run CP/M on 8085's but they are a less common than Z80 regarding microcomputers.

If you are considering designing your own SBC you should consider using the 8085 as the CPU since it is possible to make very low chip count machines with them. I hope this helps explain things. Feel free to ask if there is anything I can better explain.

Thanks and have a nice day!

Andrew Lynch

 

[NobodyIsHere]

Hi All,
Things are going well tonight so far. I just finished up the build on the SBC and everything is installed and seems 100% operational. I did some testing with the RTC and that seems to work fine. Did some testing with XMODEM 5.0 and that works OK too. XMODEM seemed like the toughest application I had so if it is working then I think things are going well. I still need to use the oscilloscope to see what signals are appearing on the ECB bus connector but as best I can tell they should be OK.

In addition, the whole minimum clearance issue has somewhat lessened in my mind. At first when I saw the tiny 6.5 mil clearances I almost panicked considering how difficult I thought they'd be to get right. However, after a complete first time build with zero learning curve on this board, I only saw maybe 3 or 4 possible solder bridges during the entire build. Those were obvious and with a little solder wick and some rather normal VOM testing, it really doesn't seem to be much of a problem.

Considering how relatively easy it was to get this far without major problems, I am starting to think I may have overreacted to the narrow clearances. Oh well, the next PCB will have about twice the clearance so I think this problem has turned out to be basically a non problem. That's my favorite kind.

OK, so as soon as this PCB finishes the optimizer, I will be ordering some boards. The manufacturer says something like 15 days turn around plus shipping. My guess is that is like 3-4 weeks or so total.

Thanks and have a nice weekend!

Andrew Lynch

 

[ziloo]

Hello,

... CP/M loads at $D400 and uses up to $F2FF...

... I seem to recall the TPA is 53K in length for some reason. 2K is used for the RAM BIOS. CCP and BDOS uses 5.5K, if I recall correctly. I think the CBIOS and disk buffers use up the remainder. The CBIOS supports an IDE interface as well which chews up quite a bit of RAM and also requires a 512 byte deblocking buffer someplace up in high RAM...

1- Is CBIOS included in the $D400-$F2FF address interval?

1- How much memory is available for an application program?

2- Is there any unported portion of CP/M still left in the EPROM?

Thank you

ziloo

 

[NobodyIsHere]

Hello,



1- Is CBIOS included in the $D400-$F2FF address interval?

Hi!

Yes, the CP/M boot image includes CCP+BDOS+CBIOS. The loader copies a memory image range of $1EFF in length (a little bit less than 8K) although the actual length of the CP/M binary boot image is somewhat less than that. CCP+BDOS are 5.5K and the remainder is the CBIOS.

1- How much memory is available for an application program?

I am not certain but I think it is 53K. After a quick review of the CPM22-d.asm code, I believe transient program area (TPA) = (MEM -7) * 1K where MEM = 60 in this case. For the most part, that is sufficient. I have found CP/M TPA 48K or greater to be pretty usable.

In theory, I could boost MEM to 62 but it'd cost the RAM monitor and since I use both about the same amount, I'd rather keep it. Also the CBIOS could probably be rewritten to be lot tighter code which would shrink it some too. However, more likely is that the CBIOS will grow not shrink since I do intend to add support for an FDC eventually which will further shrink the TPA probably another 1K or so.

Now this design is largely out in the public, there is nothing stopping anyone from creating their own ROM images and custom CBIOSs. In fact, I rather encourage it. I will speak with my friend to see if he can add support for the N8VEM hardware into a simulator. It should be fairly easy as there are only 5 simple IO devices.

2- Is there any unported portion of CP/M still left in the EPROM?

No, it is all converted as best I can tell. The rest of CP/M ia/are transient programs which are identical for all CP/M distributions. Those include STAT, ASM, DUMP, PIP, LOAD, etc. Those are currently stored on an IDE HD partition which I haven't attached yet but will be in the not too distant future. However, if anyone wants to use them now, they can boot the computer, start CP/M and use XMODEM to transfer the files to the RAM drive where they'll reside as long as power is applied.

Thank you

ziloo

Thank you! Have a nice weekend!

Andrew Lynch

 

[ziloo]

DAndy board

DAndy board

Hello Andrew,

1- Please explain in more details about communication between
Dandy board and something like Hyperterminal.

2- Can you download a file from a PC to Dandy board?

3- If so, which software is responsible for communication: Ram Monitor
or Xmodem?

p.s. How do you like the nickname for your board ...:D


ziloo (I actually smile like this guy!!)

 

[NobodyIsHere]

Hello Andrew,

1- Please explain in more details about communication between
Dandy board and something like Hyperterminal.

Hi!

Yes, I use Hyperterminal to communicate with the SBC over the serial port. There is a custom serial cable required and I suppose I need to publish the plans for it as well. I'll do that. Funny you should ask about Hyperterminal though as I have been working on the serial connection. Up until today, the SBC used 3 wire serial connection with no flow control at all. That is really not my preferrred approach but I never could figure out how to make hardware flow control work properly.

So this morning I got out the RS-232 serial break out box and the pin outs for the PC serial port and the 16C550 datasheet. I think I have fixed the problem so now the SBC appears to be using hardware flow control. Still, I need to verify it is working. The custom serial cable is pretty easy to make and when I confirm it is working I will post how to make it.

2- Can you download a file from a PC to Dandy board?

Yes, you can use XMODEM to send and receive files from the SBC.

3- If so, which software is responsible for communication: Ram Monitor
or Xmodem?

You can use either to transfer a file from a PC to the SBC. Using XMODEM is probably easier or you can use the Intel Hex transfer utility in the RAM monitor. To send a file from the SBC to the PC just use the XMODEM or text capture.

p.s. How do you like the nickname for your board ...:D

Whatever does it for you!

ziloo (I actually smile like this guy!!)

Thanks and have a nice weekend!

Andrew Lynch

 

[ziloo]

Hello Andrew,

1-Upon starting the SBC, under which supervisory program does the Dandy board
eventually end up...the Monitor or CP/M?

2- How do you transfer operation from one to the other?

3- Xmodem is a whole separate program, and CP/M is not aware of its presence;
because Xmodem is the communicating program for CP/M, it could not be called in
by CP/M like some other utility programs on the HD/FD/RamDrive. So it is kind of a
CBIOS extention...Do I understand this correctly?

ziloo

 

[Druid6900]

I prefer da' Andy Board, personally.

 

[NobodyIsHere]

Hello Andrew,

1-Upon starting the SBC, under which supervisory program does the Dandy board
eventually end up...the Monitor or CP/M?

Hi!

After pressing the RESET button and waiting a few seconds, the SBC comes up in the RAM monitor mode. You can boot into CP/M by pressing the "c" key and waiting another few seconds. It is not instantaneous because the initialization routines clear all the RAM to a known state and format the RAM drive which takes a few seconds. It is quiet though...

2- How do you transfer operation from one to the other?

From the RAM monitor to CP/M, press "c" to boot CP/M

From CP/M to the RAM monitor, type the "gm" command for "go monitor".

You can switch in between the two quite easily.

3- Xmodem is a whole separate program, and CP/M is not aware of its presence;
because Xmodem is the communicating program for CP/M, it could not be called in
by CP/M like some other utility programs on the HD/FD/RamDrive. So it is kind of a
CBIOS extention...Do I understand this correctly?

ziloo

Well ... not quite. XMODEM is a CP/M program in its own right although it does have its own unique CONIN, CONST, and CONOUT routines instead of using the ones provided by the BDOS or CBIOS.

You call up the XMODEM program by typing "xm" at the CP/M prompt. It is just like any other CP/M program for the most part. It uses BDOS routines for its file access for instance. The RTC also uses some BDOS routines. I suppose they could be stand alone programs but why rewrite all those file IO routines when CP/M provides them so nicely?


Thanks and have a nice weekend!

Andrew Lynch

PS, it is beautiful outside today so I am going to go mow the lawn!

 

[NobodyIsHere]

I prefer da' Andy Board, personally.

Thanks!

Andrew Lynch

 

[ziloo]

Hello Andrew,

Accoring to buildTP2.bat file:
Xmodem is assembled and linked to CP/M and few other programs to
create a binary file to be downloaded as Rom image.

Was it possible that Xmodem could have been treated like any transient program
that could be loaded by CP/M into Ram, but for now it is manually linked to the CP/M
program. If so, then the "XM" command has been manually added to CP/M (in the absence
of an storage device for Xmodem program)?

ziloo

 

[NobodyIsHere]

Hello Andrew,

Accoring to buildTP2.bat file:
Xmodem is assembled and linked to CP/M and few other programs to
create a binary file to be downloaded as Rom image.

Was it possible that Xmodem could have been treated like any transient program
that could be loaded by CP/M into Ram, but for now it is manually linked to the CP/M
program. If so, then the "XM" command has been manually added to CP/M (in the absence
of an storage device for Xmodem program)?

ziloo

Hi!
Oh, I think I see the misconception here... XMODEM is not linked to the CP/M boot image. It is a transient program like RTC and GM or any other CP/M transient program. XM is in the same ROMIMAGE binary because the ROMIMAGE is basically just like a miniature disk image. They are together like various programs would be on a regular disk but XM is not linked to CP/M. It is written in pure assembler and only called into RAM when the CCP requests it. It does use BDOS calls but so does almost every CP/M program.

You'll notice that the loader, dbgmon, and CPM boot image are all on the first five 2K system tracks which are $0000 - $27FF (10K) in the ROMIMAGE. The CP/M directory sectors are at $2800-$2BFF (1K) and the programs themselves are stored in the data sectors $2C00-$7FFF (21K).

I have been testing XMODEM as part of my attempts to get a documented serial cable. I think I have a working prototype cable that works with hardware handshaking. One thing I have noticed is that the new PCB seems a lot more solid and reliable than the previous prototype board version. It used to be that XM was rather flaky but now it seems rock solid. I can load XM in to RAM, run it, pull data files from the PC and back again without the slightest hiccup or even a retry. That is quite different than before. I've been doing the transfers with large ZIP files as they are easy to detect if there is file corruption being introduced.

Thanks and let me know if this helps explain how this all works. Just try to think of ROMIMAGE.BIN as a miniature disk image, not an executable. Really the only thing in ROMIMAGE.BIN which actually executes in place is the loader. Everything else is just so much data -- just like on a floppy disk. Not until the OS pulls the data into RAM does it become real executables.

Have a nice day! I am going for a run while the sun is still out!

Andrew Lynch

 

[ziloo]

Hello Andrew,

...the programs themselves are stored in the data sectors $2C00-$7FF...

Now, what is the use for the higher EPROM address range, namely $8000-$FFFF?

You can get a directory of the three programs I placed into the ROM image. If I recall
correctly, they are gm (go monitor), RTC (real time clock) and XM (XMODEM). There are
supposed to be a bunch more but since I have to hand code the directory entries into
the ROM image I have only done those few programs.

Would you please explain about "hand coding"...

ziloo

 

[NobodyIsHere]

Hello Andrew,



Now, what is the use for the higher EPROM address range, namely $8000-$FFFF?

Hi!

In its current implementation, the ROM drive is only a single 32K page so there is nothing in outside the first page (ROM page 0, $0000-$7FFF). It is an artifact from the original design that used a 28C256 EEPROM (32K). However when I get the CBIOS updated with the new design, the ROM drive will have 32 32K pages for 1MB total capacity from the 27C080 EPROM.

From a CPU perspective, the ROM only appears as $0000-$7FFF in its lower memory page window. The ROM never appears in $8000 or above. The MPCL set the upper address lines so that you can see one of the 32 32K "windows" into the ROMs address space.

Would you please explain about "hand coding"...

ziloo

Yes, the "hand coding" is literally typing in the characters for directory entries manually. If you'll look in the ROMFRMT.ASM file you'll see the data entries of the three CP/M transient programs. Making manual entries is pretty labor intensive compared to just letting CP/M BDOS do it automatically for you. If you want to add a program, ROMFRMT.ASM has to be updated as well where ever the data image would reside in the ROMIMAGE.BIN.

Thanks! Have a nice Sunday!

Andrew Lynch

 

[ziloo]

Hello Andrew,

I have really enjoyed our "Socrates dialogues" ... :argue:
You might have noticed that this thread has had hundreds of readers over the past
few days, so there must be great interest in learning about SBCs running CP/M.
Now, why not getting into more details:

... the "hand coding" is literally typing in the characters for directory entries manually. If you'll look in the ROMFRMT.ASM file you'll see the data entries of the three CP/M transient programs...

org $2800
.db $00,"GM COM",$00,$00,$00,$01
.db $01,$00,$00,$00,$00,$00,$00,$00
.db $00,$00,$00,$00,$00,$00,$00,$00
.db $00,"RTC COM"...

Would you please go over the entries and explain what they are all about...:winking:

Thank you

ziloo

 

[NobodyIsHere]

Hello Andrew,

I have really enjoyed our "Socrates dialogues" ... :argue:
You might have noticed that this thread has had hundreds of readers over the past
few days, so there must be great interest in learning about SBCs running CP/M.
Now, why not getting into more details:





Would you please go over the entries and explain what they are all about...:winking:

Thank you

ziloo

Hi! Sure, no problem. I am glad you enjoy it and I look forward to helping you and others as much as I can. All I did with the ROMFRMT.ASM program is what BDOS normally does when it creates a file in the block device. Each file has a 32 byte entry with various pieces of metadata such as user, filename, the number of records, number of extents, where the file is on the disk, etc. CP/M has a very straight forward file system so doing this is much easier than it may sound. Here is a link with a good explanation although there are more detailed explanations in the CP/M documentation. I think the CP/M Alteration Guide is pretty good and the Andrew Johnson-Laird book "CP/M Programmer's Guide" has an excellent description.

http://www.geocities.com/homeofoscarvermeulen/cpm.html?200811#Directory

Please bear in mind though, I am not a CP/M guru or even an expert on vintage computers or electronics. I am but a child student at the feet of the real masters. Allison, Chuck, Mike, Howard, Dave, et al, have probably forgotten more about CP/M and vintage computers than I'll ever know.

One of the benefits of building your own computer from scratch is it forces you to learn the practical aspects of those theoretical concepts of computing you probably learned in college. I know I have and that is why this hobby has paid for itself many times over for me. I can only recommend diving in and building something. In my engineering day job, we tend to focus on the more business aspects of things, however, I am expected to keep technically current and there is nothing better than grabbing the hot tip of a soldering iron to remind you which is the business end...

At any rate, things are going well today. I contacted my friend who is a simulator expert and he has a preliminary version of the N8VEM coded up in a popular computer simulator. I tried a pre-release version already and it works so well I was able to code up a revised CBIOS to support the 1MB ROM as the F: drive without ever touching the SBC itself. Now I can run the simulator and do all the programming on the nice PC in a comfortable chair. When I am satisfied it is working, take the resulting ROMIMAGE.BIN on a floppy disk downstairs, burn an EPROM, plunk it into the SBC and presto! instant working program.

Normally debugging the CBIOS on target hardware can be a chore but now it is a breeze. I updated the CBIOS and now the F: drive contains the CP/M transient programs. I am going to upload a new set of N8VEM software tonight. Once I get clearance from my friend to release the simulator, I will do that as well assuming he will release it. I am pretty confident he will but just in case, I will hold off until he gives explicit permission to publish.

Soon you'll probably be able to take the N8VEM SBC out for a test drive on your PC to see how it works for you. Literally its "try before you buy" to see how the system works before investing in the PCB or the parts needed to build it.

Which brings up another point, it is way off topic but please let me digress; if you had a nearly empty 1MB ROM disk on a SBC what sort of programs would you put on it? My thinking was the basic CP/M transient programs would be cool. Now that those are there though I recognise that takes up practically no space at all. Of the 992K available, the CP/M transient programs only take up about 56K leaving 926K available for other programs. Got any ideas? Probably a good start would be a utility tool set with a decent editor. ED is *not* your friend. ;-)

Thanks and have a nice day!

Andrew Lynch

PS, I forgot to mention that today is the first time I tested the actual 27C080 EPROMs with the SBC design. They work as expected but I was surprised how l o n g they take to program and verify. I am finding I am really partial to the 27C1001 128Kx8 EPROMs instead. They are cheap, plentiful, practically disposable, and program quickly, MUCH quicker than the 27C080s do. I may hold off on the 1MB EPROMs until the very end as they are PITA to work with. Ah, the joy of discovery. :-/