Update Log

[ MainPage | UpdateLog | Downloads | BBS ]

Update log, or you can say it is just a memorandom. :-)
Now I'm working on two things.

After enabling network support with a bit of unstableness, now I'm working on a dynamic loading library on my PC-6001 Contiki, which will be also available on any Z80-based machines. The biggest problem is memory limitation. For example, I can pick it ELF format, but loading mechanism itself would be too large to fit in small memory footprint. Therefore, I consider introducing another mechanism of dynamic loading. I don't want to reinvent the wheels, so if you know any good alternative, please inform me!


After struggling a bunch of problem, finally I added my PC-6001 support sources to the main Contiki CVS in Sourceforge.net. The last problem was an RS-232C driver, which is based on polling rather than interrupt as you can see as other ports.


I struggled with memory and finally made it! Web server is now on memory, I don't have any network hardware driver though.

My hard road was the following:

  1. CTK conio routine were totally rewrited, because a platform provider can supply the module. 2,006 bytes reduced.
  2. Transport the code to assembler whatever has assembler options. Basically, checksum calculation routines were transported into the assembler code. 567 bytes reduced.
  3. As for webserver, I made functions optional as much as possible. By this work, CGI-support, embedded files other than "404 File not found", and SHTML inline script support are made to be optional and erased from the binary. 5,970 bytes reduced.
  4. In psock.c, I found a "printf" was used, so I made it optional. 3,061 bytes reduced.

With these work, total 11,604 bytes reduced! Now this configuration could run on PC-6001, with some more effort regarding the network hardware support.

As for network hardware, I don't have RS-232C option on my PC-6001, so I need to get it.


A few days ago, I became a commiter of Contiki project at sourceforge. As a first step, I committed z80-depend code. Once I make the code clean, I will commit PC-6001 code as well.


Now I'm moving on to the networking. In contiki system, some functions, which calculate checksums, are intended to be overridden in assembler code by the performance reason. Therefore, I wrote the whole checksum routines in the native z80 code. Code size, however, is still too large to settle in RAM area. I need some breakthrough to make the networking work.


Finally, I made the multithreading function work!

The symptom and resolution was following:

  • Once activated multithread sample program, "?SN Error" occurs infinitely.
  • I checked the context switching mechanism, which swaps all registers, but none error was found. The stack switching seemed to work properly.
  • I noticed "?SN Error" was caused by 2msec timer interruption of PC-6001. Therefore I checked if a timer interruption vector (0xfa06) is changed during execution, but it is not changed.
  • Using PC-6001VW monitor functionality, I found the interruption called 0x000d.
  • I noticed that the context switching mechanism swaps all registers including "I" register, which indicates higher byte of interruption vector.
  • That's the reason why! Initial value (first context switch) of the registers are unknown, because the thread is yet started. Therefore the value of "I" is also unknown at that point. My "overworked" register switching caused this! In fact, we don't need to save/restore "I" register.

After removed register save/restore of "I" and "R", everything works fine! Most of Z80-based computer can use this context switching mechanism, so I will commit this on cpu-dependent directory rather than machine-dependent directory.


Porting multithreading library is not going well. Contiki itself has two types of multithread libraries:

  • Protothread - very lightweight multithreading library. It is used as default for switching processes.
  • Multithread - more architecture-specific multithreading library. You can use it as machine-independent code from appcalitions, but in the mechanism it requires machine-specific thread switching.

I know the enough mechanism of z80 for implementing the z80-specific thread switching according to the Contiki system, but it doesn't work somehow...


Now trying to implement z80-dependent multithread library. I implmented it by following existing architecture-dependent libraries. The context switch must include saving registers and a stack pointer, so I wrote this part by assembler. It doesn't work well yet actually. Definitely I miss something...


I posted a set of patch regarding z80 to the contiki developers mailing list, so I hope it would be applied soon.
Currently the biggest problem is the size of the load module, which enables networking and GUI. The size exceeds the capacity of PC-6001, when the both of components are set to be available. The reason of this includes poor code generation of sdcc. For example, sdcc emits code for "switch" of the char type like this:

C code:
   switch (c) { // suppose c is char type
     case 1:
       // do something A
     case 2:
       // do something B
       // do something C
Corresponding Z80 assembly code:
	ld	a,4(ix)		// 3 bytes
	sub	a,#0x01		// 2 bytes
	jp	Z,00101$	// 3 bytes
	ld	a,4(ix)		// 3 bytes
	sub	a,#0x02		// 2 bytes
	jp	Z,00102$	// 3 bytes
	// do something C
	jp	Z,00103$	// 3 bytes
	// do something A
	jp	00103$		// 3 bytes
	// do something B
It costs 22 bytes for branches. As you see, the code size of each "case" would be bigger using destructive "sub" than using "cp". I suggest the following:
	ld	a,4(ix)		// 3 bytes
	cp	a,#0x01		// 2 bytes
	jp	Z,00101$	// 3 bytes
	cp	a,#0x02		// 2 bytes
	jp	Z,00102$	// 3 bytes
	// do something C
	jp	Z,00103$	// 3 bytes
	// do something A
	jp	00103$		// 3 bytes
	// do something B
In this way, it costs 19 bytes. You don't see much difference for this small example, but if the number of case increases, the difference becomes bigger. If you have N "cases" plus a "default", you can calculate the size by the following formula:
  size = 8 * (N - 1) + 3 * (N - 1) = (N - 1) * 11
where my example shows:
  size = 3 + 5 * (N - 1) + 3 * (N - 1) = 8N - 5
The difference would be:
  diff = ((N -1) * 11) - (8N - 5) = 3N - 6
It doesn't makes a big difference, unless the variable N is big, but I can show some examples:
ctk.c: N=8, N=6, N=4, N=4: total difference=60bytes

I know this is just a single case for "switch (char)" type of code generation. I wonder, however, it would be some other size optimization possibilities in sdcc. It also improves performance, because accessing index registers cost much state than other operators.

Now I'm successfully working Contiki-2.0 on PC-6001. Ported modules are very small part of the contiki system. It does not support any networking, and it just supports a few applications, but it IS working!
I started working on the 2.x-branch of contiki. Now the compilation is succeeded with some efforts for SDCC newer version (2.7.0). It does not work on an emulator at all, because the binary size is approximately 32kB w/o any applications! Definitely I need extra work to reduce a bunch of modules...
Finally I put an early version of contiki-p6 file on download page.

As you may see, current PC-8801 port of Contiki is very plain, there's neither color, even nor a reversed attribute.  That is, you have to operate Contiki blind.  Now I'm trying to address it, though it seems somewhat hard to control text attribute area of PC-8001/8801, because of its strange structure.

A web server served by Contiki on Commodore64 is now working at http://www.tfe.c64.org/.  It is actually serving HTML pages, PNG images, and some CGIs! It's totally amazing! 

Similar to 6502 version of Contiki, I realized my version can be ported other Z80-based computers, too.  Actually I'm preparing Contiki for other machines in quiet. :-)

hex2cas is updated to version 1.0.1, which is available on PC-6001mk2 as well as on PC-6001 16kB/32kB modes.

Now Contiki-p6 works on mk2 mode.  Soon I will put that test version and mk2-available hex2cas on the site.

Contiki-p6 test version is released.  This is just "find-how-it-looks-like" version. ;-)

Ishioka-san (original author of iP6) provided me the BIOS information about PC-6001.  Thanks to it, now I can handle key event properly and the Contiki-P6 works with an additional emulator; PC-6001VW.

Adam (original author of contiki) did great efforts for the workaround of sdcc stuff with my request.   Actually it was a sort of surprise, because my careless cvs update made loads of conflicts in my source tree, without an expectation of this kind of change.
Now I'm moving on networking stuff...how can I carry out the physical thing like RS-232C??

BTW, ctk module for P6 is based on ctk-conio.  Today I made this ctk module smaller for a few kilobytes, because the memory issue is getting bigger...it's hard to put things in 32kB area...

With my request, some of Japanese sites are now linked from Contiki's press page.  It seems somewhat interesting that Japanese sites are linked from a non-Japanese site.  I hope many Japanese people follow that link.

hex2cas was put on my site.

As a request, I'm preparing to unveil my little tool for converting hex file to PC-6001's cas file.  I hope it can be available soon.
Anyways, I wonder there is any tool for converting a cas file to a REAL cassette sound?

This site was introduced on Contiki home page!

This site has been open to public.
I'm sorry, but I didn't prepare Japanese version...because it is burden to do maintenance two versions simultaneously...