P8000

Some of the libc objects are containing extended instructions for external processing like by an FPU. I have no idea why the libc contains that stuff because there is just no FPU but ok... At first I started by creating a program using this function (pow10() in this case). Then I disassembled it:

0044                 abf3  dec     r15,#4
0046             0ffcc401  ext0f   #%0ffcc401
004a             8e04c640  ext8e   #%8e04c640
004e         14023f800000  ldl     rr2,#%3f800000
0054             0b071388  cp      r7,#%1388
0058                 e705  jr      c,%0064
005a                 a52e  set     r2,#14
005c             8f088201  ext8f   #%8f088201
0060                 a9f3  inc     r15,#4
0062                 9e08  ret     

The ext8f and ext0f opcodes are the extended instructions. To find out how the instructions are called in PLZ/ASM I used the systems debugger to disassemble this portions of the code to find out the mnemonics:

#61 adb a.out
ADB: P8000 1.6
? 0x0044/i
%0044:          dec     sp,#4
? 0x0046/i
%0046:          fldctl  @sp,fflags
? 0x004A/i
%004a:          fsetmode        rn
? 0x004e/i
%004e:          ldl     rr2,#%3f800000
? 0x005c/i
%005c:          flds    f0,r2
? 

So now a simple PLZ/ASM Programm can be created:

pow10 module
  global
    _pow10 procedure
      entry
        dec     r15,#4
        fldctl  @r15,fflags
        fsetmode rn
        ldl     rr2,#%3f800000
        cp      r7,#%1388
        jr      c,L1
        set     r2,#14
        flds    f0,r2
        inc     r15,#4
        ret
L1:
    end _pow10
end pow10

And when assembling it, as(1) has to be called with the -f switch to enable floating point instructions. After this - you see an object dump and when you compare it with the binary hex printout in the disassembled listing above you see that it matches

#66 as -f -o pow10.o pow10.s 
#67 objdu pow10.o
File pow10.o
Image size:     32
Bss size:       0
Entry point:    0x0
Segment 0
Text size:      32
Data size:      0
Bss size:       0
Text......

0000:     abf3  0ffc  c401  8e04  c640  1402  3f80  0000
0010:     0b07  1388  e705  a52e  8f08  8201  a9f3  9e08
Data......

#69 

Since the last week I'm trying to rebuild the libc from WEGA. I first had a look at the libc implementation of V7 and SYSIII where I have the sources. I saw that the syscall implementations where written in Assembler so this will be easy by just disassembling the WEGA objects and tidy them a bit up. So I started with them.
I got all the object files out of /lib/libc.a using ar(1). Fortunally there was a Library.SC file in it containing all the SCCS what-Strings so it was easy to see if the original source files where Assembler or C sources. I picked all the assembler sources which where belonging to libc/sys (system calls) and used objdu(1), nm(1) and my disassembler as well to recreate valid PLZ/ASM Sources. After all this was done, I just took the C sources from V7 for the other libc objects and compiled them all. Some of the compiled objects where already matching the WEGA objects so this was easy. For the non-matching objects I had to disassemble them to find the differences. Most of them I got already to compile to an identical image. It takes some time to find out what Assembler statements might be the reflection of what C code.
The hard part starts now by having some objects left where no V7 or SYSIII equivalent exists. For the big objects I see no real chance of getting them back as C source since it is just to much to do. And without an idea what the function is for it gets hard.... I did this for a small object and I'll show what I did to get to the C source here:

1.) Dump the relevant Machine code out of the object

#131 objdu goodmagic.o
File goodmagic.o
Image size:     102
Bss size:       0
Entry point:    0x0
Segment 0
Text size:      82
Data size:      20
Bss size:       0
Text......

0000:     abf5  6ffe  0004  2ff7  4d08  0000  61f2  0000
0010:     6f02  0000  bdea  abe0  a1e2  81e2  61f3  0000
0020:     4b23  0000  eef8  8de4  ee0b  a137  5f00  0000
0030:     6ff2  0000  6102  0000  6900  0000  8d24  e6e6
0040:     8de4  ee02  4d08  0000  a1e2  61fe  0004  a9f5
0050:     9e08
Data......

0000:     0000  e707  e711  e705  e607  e611  e605  e507
0010:     e511  e505
#132 

2.) The next step is to get an idea of what function/symbols are stored in this object:

#130 nm goodmagic.o
    0000 T _goodmagic
    0000 D _magics
         U _swap
    0002 C _swap_flg

3.) Now the disassembler can be fired up on the objdu-Output above (Note - I already commented the code for your understanding!)

0000         0000  .word   #%0000 ;RST
0002         0000  .word   #%0000 ;RST FCW
0004         0000  .word   #%0000 ;RST SEG
0006         0000  .word   #%0000 ;RST PC
0008         abf5  dec     r15,#6		!reserve 6 bytes on the stack (r15=stack pointer)!
000a     6ffe0004  ld      %0004(r15),r14	!whatever is on r14, save it in the last of the!
						!two reserved SP bytes (0004-0005)!
000e         2ff7  ld      @r15,r7		!store the 1st parameter of goodmagic() at the!
						!beginning of the stack!
0010     4d080000  clr     %0000		!initialize the ext. var "swap_flg" with 0x0000!
0014     61f20000  ld      r2,%0000(r15)	!===>LABEL0 - load the 1st parameter of goodmagic()!
						!into r2!
0018     6f020000  ld      %0000,r2		!load this r2 into the beginning of the comp-struct!
						!"magics" where all magics
                                                !are in (see Data section in objdu)!
001c         bdea  ldk     r14,#10		!set an internal loop-counter (r14) to 10 (amount!
						!of elements in "magics")!
001e         abe0  dec     r14,#1		!===>LABEL1 - decrement the loop-counter by 1!
0020         a1e2  ld      r2,r14		!load the counter into r2!
0022         81e2  add     r2,r14		!double r2. this is being done because the elements!
						!in "magics" are 2 bytes of size so the 1st position!
						!is 0000 and the second is 0002 and so on.!
0024     61f30000  ld      r3,%0000(r15)	!load 1st parameter of goodmagic() into r3!
0028     4b230000  cp      r3,%0000(r2)		!compare r3 with the data in the magics struct at!
						!position "r2" (position "loop-counter"x2)!
002c         eef8  jr      nz,%001e		!if not equal GOTO LABEL1!
002e         8de4  test    r14			!so... if equal and the loop-counter is not 0...!
0030         ee0b  jr      nz,%0048		!GOTO LABEL3!
0032         a137  ld      r7,r3		!now store the prrevious filled r3 (1st parameter of!
						!goodmagic()) into r7 which is itself the 1st para-!
						!meter of the next called function swap()!
0034     5f000000  call    %0000		!call swap()!
0038     6ff20000  ld      %0000(r15),r2	!1st parameter of goodmagic() gets overwritten with!
						!the return value of swap()!
003c     61020000  ld      r2,%0000		!load the external variable swap_flg into r2!
0040     69000000  inc     %0000,#1		!increment swap_flg by 1!
0044         8d24  test    r2			!if swap_flg was 0 before it got incremented (1st!
						!loop run, first time swap() got called)!
0046         e6e6  jr      z,%0014		!GOTO LABEL0!
0048         8de4  test    r14			!===>LABEL3 - check loop counter!
004a         ee02  jr      nz,%0050		!if not equal 0 (magic found), GOTO LABEL4!
004c     4d080000  clr     %0000		!if 0, reset swap_flg to 0x0000. if no magic was!
						!found, swap_flg is always 0 - independent of the!
						!fact that it was called!
0050         a1e2  ld      r2,r14		!load the loop counter into the return register r2!
0052     61fe0004  ld      r14,%0004(r15)	!reload r14 from the stack!
0056         a9f5  inc     r15,#6		!give the 6 byte used for this function from the!
						!Stack free!
0058         9e08  ret     			!return

4.) Create the corresponding C-Code:

#include 

int swap_flg;
int magics[10] = {
	0x0000,
	N_MAGIC1,N_MAGIC3,N_MAGIC4,
	S_MAGIC1,S_MAGIC3,S_MAGIC4,
	X_MAGIC1,X_MAGIC3,X_MAGIC4
};

int
goodmagic(magic)
int magic;
{
	register int ret;
	
	swap_flg=0x0000;

	do {
		magics[0]=magic;
		ret=sizeof(magics)/sizeof(int);

		do 
			ret--;
		while (magic!=magics[ret]);

		if(ret)
			break;

		magic=swap(magic);
	} while(!swap_flg++);

	if(!ret)
		swap_flg=0x0000;

	return(ret);
}

I consider the RTC to be ready for usage now.
- I created the schematics and a PCB layout (not tested yet):
- I built the RTC:


- I created a standalone program and a kernel module (scroll down):

#16 make
        cd standalone ; make all
        cc -O -I../common -c sa.timer.c
        cc -c -O -I../common ../common/u130.c
        cc -c -O -I../common ../common/rtc72421.c
        cc -c -O -I../common ../common/gmtime.c
        cc -c -O -I../common ../common/timegm.c
        ld -s -o sa.timer sa.timer.o u130.o rtc72421.o gmtime.o timegm.o libb.a
        chmod 400 sa.timer
        cd kernel ; make all
        scc -O -I../common -c timer.c
        scc -c -O -I../common ../common/rtc72421.c
        scc -c -O -I../common ../common/u130.c
        scc -c -O -I../common ../common/gmtime.c
        scc -c -O -I../common ../common/timegm.c
        touch kernel
#17 make instsa
        cd standalone ; make install
A backup of the old sa.timer can be found here: /sa.timer.orig
        sh -c 'if test ! -f /sa.timer.orig ; then \
                cp /sa.timer /sa.timer.orig ; \
        fi'
        cp sa.timer /sa.timer
#22 make instkern
        cd kernel ; make install
I will now include the new objects in the kernel library LIB1.
A backup of the old LIB1 can be found here: /usr/sys/sys/LIB1.orig
        sh -c 'if test ! -f /usr/sys/sys/LIB1.orig ; then \
                cp /usr/sys/sys/LIB1 /usr/sys/sys/LIB1.orig ; \
        fi'
        ar rv /usr/sys/sys/LIB1 timer.o rtc72421.o u130.o gmtime.o timegm.o
r - timer.o
r - rtc72421.o
r - u130.o
r - gmtime.o
r - timegm.o
You should now go and build a new WEGA kernel to get the RTC up and running
#23 cd /usr/sys/conf
#24 make -f make.wega
        chkout  ver.c+
        Version 3.2
        4 lines
        scc  -c ver.c
        sld -Ns -o wega -e start -X -i -Ms62 wpar.o event.o mch.o u.o ver.o fpe.o conf.o ../sys/LIB1 ../dev/LIB2
        rm -f ver.o ver.c
#25 mv wega /wega
#26 chmod 400 /wega
#27 halt

HALT PROCEDURE STARTED AT Sun Aug 16 22:28:46 MES 2009
Broadcast Message ...

        System is coming down.  Thirty seconds to forced log-off.
Current logged in users:
wega     console Aug 16 22:07
HALT PROCEDURE COMPLETED AT 
Sun Aug 16 22:29:19 MES 2009
Now terminating all processes

P8000 WEGA
Single-User Mode
#1 sync;sync
#2 
U880-Softwaremonitor Version 3.1 - Press RETURN
>x                                             

U8000-Softwaremonitor Version 3.1 - Press NMI
 O D
BOOTING FROM HARD DISK
> boot



Boot
: 
md(0,16000)wega

-------------------------------------------------------------------------------
WEGA Kernel -- Release 3.2 -- Generated 08/16/109 22:26:34                     
Copyright  1986  ZFT/KEAW-WAE                             
                             
System: P8000   Node: WEGA      Release: 3.2    Version:  3.1 4/5
                                                                 
number of users         = 8 
size of user struct     = (1394/0x572) bytes
address of user struct  = 0x3E00F600        
kernel memory size      = (173568/0x2A600) bytes
user memory size        = (1661440/0x195A00) bytes
file system /usr        = offset 0, 13000 blocks  
swap space              = offset 13000, 3000 blocks
file system /           = offset 16000, 7000 blocks
file system /tmp        = offset 23000, 4000 blocks
file system /z          = offset 27000, 146376 blocks
-------------------------------------------------------------------------------
                                                                               
Seiko Epson RTC-72421 found
                           
P8000 WEGA
Single-User Mode
#1 date
Fri Aug 21 22:18:38 MES 2009

As the topic already tells, there was much stuff ongoing lately. I managed to create the circuit diagram for the original RTC delivered in the P8000 Compact. I also acquired quite some time ago the original clock modules which where used for this RTC. Some friends helped me out with ICs which where no longer produced so I got the chance to build up my own RTC re-implementing the original one. The clock itself works nicely and some photos can be seen here.
I successfully wired the clock in PCB to create circuit boards. This made us able to produce a small number of RTCs for the P8000. But due to the fact that some ICs are no longer aquireable and the clock itself supports only dates up to 2019, I decided that it would be better to build a new RTC. This new RTC will utilize the RTC72421 chip from Epson. This eases the layout quite a lot and all components can be bought nowadays. The down side is that a new sa.timer must be written and kernel support for that has to be implemented.
I already took the existing sa.timer source and changed it so it is now completely modular and can handle two different RTC cards by detecting which one is plugged and using the proper functions then. I'm now about to solder my Epson-RTC together to implement the Epson specific part into the Program. The kernel part will be then the next part.

Enrico managed to build up a new RAM card in the meantime supporting up to 16MB of RAM (only 8 MB usable right now in WEGA). Some pictures of that card can be seen here
After some errors in the GAL firmware where found and corrected - which also included some wiring on the board - the board now works from the refresh-cycle point of view correct. This means - the data in the RAM does no longer get lost. But a kernel can still not be compiled with this RAM module - the system (csh in this case) just hangs. Right now we have no idea where the problem lies.

One more thing is, that Holm Tiffe repaired my broken P8000 WDC which I got in my original P8000 in 2005 for exchange of another broken P8000 WDC I acquired some time ago. So I changed two broken ones for one working one you could say.

Holm also found out how to generate the 16 Bit Firmware with the Sources I got so we are now able to do change and generate it properly.

I also changed some things on my webpage. I moved for example all my P8000-related sources into a CVS repository and removed them from my webpage. A nightly cvs export will now put the sources in a tar.gz archive so normal users are able to fetch them. Changes can now be easily seen with the WebCVS GUI.

Quiet some time ago I've got a Seagate ST1100 ST506 harddisk which has a size of 84MB. But until now it was not possible to use the full capacity of this drive because more then 8 heads where not usable and the ST1100 has 9 heads.
By looking at the circuit diagrams and the host controller I found out today, that the signal "head select 3" (HS3) was connected to pin 32 of the control connector of the host controller. Regarding the ST506 standard, pin 32 should carry the "drive select 3" signal and not the HS3 which should be on pin 2 of the control connector. So the host controller has an error here.
To not change the host controller itself, I modified the control cable for connecting a disk drive to the controller and routed pin 32 to pin 2 by cutting and soldering the corresponding wires together.
With this small fix, it is now possible to use the full capacity of the ST1100 disk (let me repeat it: 84MB woaaaaah). I now may use disks with 16 heads maximum.

Since 3 days I'm working to get the Sources of the Kernel by collecting C-Sources compiling them and adjusting them until the resulting binary is 100% compatible to the original object file. I've started with LIB2 (sys/dev) because I have most sources files already. Some of the objects in this Library where made by ASM listings instead of C-Sources. Yesterday I disassembled one of those objects the first time (in my life ) by hand using a opcode listing and the resulting asm code compiles now to 100% the same object - this took me about 4 hours .

Objectdump of the original file: clist.obj

My resulting ASM file: clist.s

Now there's only tty.c and tt0.c left and I got LIB2 complete...

Today I found the bug which caused the checksum calculation going wrong sometimes. So FTP receiving works now completly. I'll now recompile a clean k5jb.k37 with only the necessary changes and will then check on storing files

# ftp 10.1.1.2
Connected to 10.1.1.2.
220  FTP version K5JB.k37 ready at Tue Apr 30 22:25:47 1991
Name (10.1.1.2:root): test
331 Enter PASS command
Password:
230 Logged in
ftp> get sa.timer
local: sa.timer remote: sa.timer
500 Unknown command
500 Unknown command
200 Port command okay
150 Opening data connection for RETR sa.timer
  2571       0.53 KB/s 
226 File sent OK
2571 bytes received in 00:05 (0.48 KB/s)
ftp> get wega
local: wega remote: wega
200 Port command okay
150 Opening data connection for RETR wega
 98723       0.51 KB/s 
226 File sent OK
98723 bytes received in 03:05 (0.51 KB/s)
ftp> exit
221 Goodbye!
#

The second topic I'm working on right now is the kernel. I want to get the complete source of the kernel so I will start getting all my Source files together and check which are already matching with the kernel by comparing the single objects. For the remaining files I'll have to check on old UNIX sources and compare their resulting ASM code with ASM code I'll hopefully get produces by a Z8000 disassembler - if I find one.

I found another error in the libc Implementation of the LCC compiler. strtok was implemented wrong which lead to an segfault when it was used. The original code was

~L2:
        ldl     @SP,rr8
        call    ~strpbrk                // rr2 <-> r=strpbrk(p,sepset)
        testl   rr2
        jr      z,~L3

but it has to be

~L2:
        ldl     @SP,rr8
        call    _strpbrk                // rr2 <-> r=strpbrk(p,sepset)
        testl   rr2
        jr      z,~L3

K5JB.K37 itself runs OK so far but sometimes the Checksums are calculated wrongly when retrieving files from the P8000 to a client.

Ok, K5JB.k37 is now running on the P8000. FTP storing works - partly - from time to time the system does not receive all data. I'm not sure if it is K5JB itself, or the com port settings on the P8000. The packet definitely leaves my FreeBSD system - snooper on a box-in-the-middle proofs this.
Lowering the speed to e.g. 600baud stops bringing up invalid checksums and missing bytes so I guess 9600 fully used is to fast for K5JB on the P8000. I've stored a file w/o a checksumming problem now but the file was only stored partial... FreeBSD's ftp program timed out before the transfer was completely done...
i've to check why the transfered file is not identical to the sent file (so it is not partial only it also is modified until the end...)
I've also to check why a telnet connection makes K5JB segfaulting.