• Please review our updated Terms and Rules here

Brief history of a home built machine.

G

GilesGoat

Experienced Member
Joined
Dec 11, 2010
Messages
138
Location
Wales
Hi guys,
new to the forum ( joined yesterday ) as this is one of the few things I actually quite "documented" in the past times you may be interested in have a look at it.

This is a CP/M ( 2.2 ) running machine I built some years ago from scratch starting literally from a bunch of components I had around on the desk.

At the present it has a 256K memory 'expansion' ( in pages of 64 Kbytes of course ) and an SPI port with the intent ( still to be done ) to attach an ENC28J60 to it and try to experiment with some eth.

The CP/M running is a 'highly modified version', I started with the usual DEC CP/M 2.2 sources you can find around then "with various cut and paste" I replaced the original 8080 CCP with a new Z80 one.

What makes this system a bit 'unusual' is that it can flip into a 'system address space' where I have a "BIOS rom" and a "BIOS ram" containing various code ( specifically routines to access the IDE disk, the bootloader and other things ).

The 256K expansion idea came cause at some point I was trying to implement that Z80 OS called "UZI" ( a kind of Unix like thing ) on it but for the moment I am still not really working that much on it.

Anyway its ( not very well updated ) story is here : http://www.gilesgoat.com/NewSite/z80part1.htm

The Ram expansion is here : http://www.gilesgoat.com/YakLog/RamExp1.jpg
it also has an RTC clock ( intended to be used for that UZI ).

At some point I was experimenting with those chips as well ( INMOS T-425 ) but that's another story : http://www.gilesgoat.com/Yak/TrTest2_1.jpg

My projects go a bit 'in waves', when I have time for them I can spend N days in a row doing things but then there can be months of "not doing anything" cause I really don't have the time.

Currently I had this 'mad idea' of "I want something with a Z8001 working" and I am planning to make up 'something else' :)
 
This looks fantastic. I have just finished reading through your website. Can you describe a bit more how you are doing fat32 file access - this looks very interesting.
 
Just a quick explanation, what got me in that idea of "FAT32" was :

1.) I don't want a disk that then can be read only by CP/M
2.) I wish an 'easy' way to move files/things

Fundamentally, after studying a bit how FAT32 works I implemented my own routines to read ( only read ) FAT32 files.

Instead of having a partitioned disk I have "disk images" that literally are just simply FAT32 files created on a PC, the file is as big as the CP/M disk and is filled with 0xE5.

When the CBIOS wants to get 'sector NNN' this depending on what disk you are ( A,B,C .. ) tries to get it from the ( fat32 ) file CPMSDK_xx.DAT where 'xx' is the disk letter.

It handles the case the sectors could be not contiguos but has a bit of caching for the FAT and the sector(s) too trying to minimse the disk access, I can do that because my memory map ( so far ) was using two different 64K pages.

I have what I call "the system page" where the first 8K are "the BIOS rom", then there are also 8K of ram and a few other things, of those 8K some are used to cache disk sectors and tables.

It's not "super fast" as it could be but allows me to have a FAT32 disk I can put in/out from a PC/anything and change/read files.

I am currently still finishing to implement a 'command' to allow me on the fly to say a thing like "change disk to disk image XXXX".

There would be other interesting things to say, I got 'half nuts' to implement interrupts in a way that "CP/M does not know they are" I kinda have a user/supervisor mode with different SP and such so I can have buffering of chars ( and not missing them when typing ) to allow me to avoid seeing 'crap' happening for example when using VEDIT and VEDIT is accessing the disk.

I also have a "input/output char translation" that can be activated to :

1.) remap VT220 input keys in a friendly way for VEDIT ( my favourite editor )
2.) remap output chars for ZAPL ( still finishing it to support overstrike )

Yes I've been mad enough to create pixel by pixel by hand a VT220 APL font :D
 
Hi! You are welcome to join us on the N8VEM homebrew computing project. All the designs are free and publicly posted so they may be useful to help expand your homebrew computer. Also, maybe we could collaborate on some common peripherals.

Thanks and have a nice day!

Andrew Lynch
 
Sounds very similar to the disk images we are using on the Propeller, http://forums.parallax.com/showthread.php?121579-qZ80-the-third-shot&highlight=qz80

These started off life as the floppy disk images from the SIMH, but we changed over the the 8mb hard disk images from the SIMH. So you can run the Altair SIMH, copy things over to the i drive and copy that onto a sd card. A blank i drive is just 8mb of E5 - so it sounds the same as yours.

There ought to be some great synergies between your project, the N8VEM and the Propeller emulations.

The one thing that has never quite worked properly on the Propeller emulation is MP/M. There is quite a lot of code out there thought, including code running five MP/M emulations on one screen. But the emulation itself crashes every few hours - maybe the handover between users is not solid?

Have you looked at MP/M?
 
I know there are probably "quite some" Z80 projects around the internet ;)

One guy I was quite a bit in touch with, about the IDE interface, was Phil from Retroleum ( http://www.retroleum.co.uk/ ).

Thing is "I wanted to invent something from 0 with my own ideas", I am sure there are lot and lot of other things around done by other people but part of the challenge was "I want to find solutions with my own head".

Otherwise it feels a bit like "getting nice stuff someone already made" and make a collage of it together, plus my time is really "sparse" I can have some time a year I can spend quite a bit on some stuff for a while but then I have to let it wait "until next time".

I heard about MP/M .. two things I TRIED to have a look at were CP/M 3.0 and the famous/infamous ZCPR3 ..

ZCPR3 'gave my head in', I mean 'still don't understand exactly what you have to do to put all that stuff up' .. quite complex I'd say ..

CP/M 3.0 .. "not very sure what big benefits you'd get from it".

The I got quite intrigued of that UZI I think one day I'll return into it, the story about the swapin/swapout was not completely clear to me plus a few other things about interrupt handling and such felt a bit "I think something is not as I think here".

I also got quite a bit 'mad' studying how to make the Hitec C compiler work "the way is needed" for that UZI implementation ( UZI is written in C with some small ASM around, small but critical ).
 
You made me wish to continue a bit more on my z80 thing :)

I have to finish that thing of the "change disk" command, actually I already have an XMODEM loader embedded into the CCP ( yes, I can because the XMODEM loader actually resides in the 'BIOS' rom and the CCP command is just a jump to it ).

To implement a "disk change" I have to study well and kinda to the same kind of thing the CCP would do when you move from 'A' to 'B' for example.

My system at boot has "the bootstrap rom" which contains a "console" with a number of things ( memory dump, peek, poke, stuff ) but most important the XMODEM loader and the 'disk loader'.

The xmodem loader allows to load up to 28K of something into ram, once is there it can be executed directly or saved to disk.

The disk in that stage as "a superminimal filesystem" or better to say is "a big file that is an array of 16x64K blocks" where you can save/load from, save means you copy from memory to disk, load the reverse.

The blocks can have a name assigned ( so can 'list the directory' and know what is in ).

The "BIOS rom" can ( as it is now ) be replaced with a 6264 RAM which allows me to load ( via XMODEM ) a new BIOS in ( while testing ) .. this saves me much burning of EEPROM, because RESET does not spoil the memory a few tricks are possible.

There are 2 bits used into an I2C port that drives a small display I ripped from an old TV box, just 4 digits but useful to spit out some debug info, the I2C protocol is all done in SW.

The system is designed to work with vectored interrupts altough "normally" it would work in polled IO mode, I had various nightmares to fix stupid bugs I had in my design for this.

It always made me upset the fact you can't use vector 0066H ( NMI ) because CP/M has stuff in there, it would have been nice if you could have used it for some debugger or such.

The ram expansion is basically "nothing much to say", except that it has the particularity to leave always the last 8K of ram address 'unswapped', this is where the "OS" ( or at least the non-remappable part ) should lie.

It adds 4 more 64 pages of ram plus the RTC, the idea was to use it for that "UZI" so instead of copying in/out from disk it should just "flip a page" when swapping processes.

So far my CP/M implemetation fits exactly in 8K, leaving full 56K for the TPA, "canonical CP/M memory map" the trick is it would be quite larger but it does call in the "BIOS rom" that is memory mapped elsewhere in another page.

The CBIOS also handles the SIO interrupts and have a "modified CONIN/CONOUT" so conin takes use of interrupts ( and a circular 256 bytes input buffer ) and conout can perform "translation" for an APL char set if enabled.

CONIN also "remaps" some input sequences ( for example VT cursor keys ) into the ones used to move the cursor in VEDIT if enabled.

I must finish that "disk change thing" and then for the moment that thing could be "frozen for a while" until I'll find some extra time to begin to experiment with that Ethernet chip :)
 
You must log in or register to reply here.
Back
Top