yeah - unix for zx spectrum

edited September 2013 in Development
I started a new hobby project. An operating system for ZX Spectrum. A unix clone. Talked to my friend about it and he asked me what if after I'm done there will be only 4 bytes of memory left for programs to run?

Told him that I'm going to write "YEAH" into them. ;) So that's how this project got its name. :)

Objectives:

1. Most important parts of operating system should fit to 16Kb ROM so that I can replace (extend) original speccy ROM. Here are my initial thoughts about what I should put there:
- start up code,
- memory management,
- task manager,
- math functions (16 bit and 32 bit arithmetics and floating point),
- real time clock (if possible - using IM1s 50Hz clock),
- tty driver (or perhaps just primitives for graphics and kbd control)
- microdrive driver
- serial port driver
- unix sys calls translation table and hooks into RAM (i.e. rewiring IM1 vector, etc.)
(if any space is left I shall also include r/o ROMdisk with common tools)

2. There will be two kernels - external and internal kernel. The one in ROM will be the internal kernel. The remaining part on the microdrive shall be the external kernel (only small binary and configuration). This will enable OS upgrading without burning EPROM again (trade off is that this part will be in RAM - but it should be relatively small).

3. Since Z80 has no MMU or superviser mode new assembler will have to be written. This assembler/linker will produce relocation table and have switches to warn programmer when he is generating dangerous code (such as HALT, IMn, EI, DI). Assembler shall be small enough to be compiled for actual ZX Spectrum.

4. There will be tiny C compiler. Also small enough to be compiled for actual ZX Spectrum and written in std. C so that it can be cross compiled. The objective should be to be able to compile OS with this C compiler and bootstrap C compiler (compile it with itself).

5. There shall be a network support called SpecNet available via IF1 network and/or via serial port to PC. It should be possible to mount PCs HDD via serial port using some simple mounting protocol enabling ZX access to 32 bit virtual hard drive.

6. A whole lot of dirty ideas comes to mind, such as /dev/mic and /dev/ear being used for tape archive or even connected to actual microphone and speaker. ;)

After 26 years I'm back to my beloved speccy. So...who's with me? :) Who wants to take part in this madness? Development environment are gnu tools (I personally use Linux but can be just as well done with Windows using code blocks or similar tools).
Post edited by tstih on
«13

Comments

  • edited January 2011
  • edited January 2011
    Dr BEEP wrote: »


    Tkrap : tstih anagrams TShit
  • edited January 2011
    I'm a little wary of a new user posting "I'm gunna code the world, who is with me". I may be wrong but am skeptical at the moment. My 2p worth - the use of a microdrive is a bad idea check out the divIDE or divIDE+ or Spectranet.
  • edited January 2011
    I can provide you with a cut-down version of Fuse which will run on a real Spectrum. Due to resource limitations, it will lack a number of features from the normal version, most notably (but not only) snapshot support. It will however feature the same quality of emulation as found in the normal version, including multi-colour support, floating bus and emulation of all Spectrum quirks.

    It will however include a number of features not found in the normal version, including:
    • Authentic TV reproduction
    • Physical compatibility with any peripheral for the real Spectrum
    • Real tape support
    • Tactile feedback identical to the original rubber keys.
    Due to legal complications, this version will not be available under the GPL but will instead be released under the same terms as Amstrad currently make the ZX Spectrum ROMs available.

    In fact, I am pleased to announce that this version is available on eBay right now.
  • edited January 2011
    I can provide you with a cut-down version of Fuse which will run on a real Spectrum.

    There's too many emulators nowadays! I'm perfectly happy with this one when it comes to spectrum emulation on a real spectrum.
  • edited January 2011
    tstih wrote: »
    So...who's with me? :)

    you are alone... honestly, im missing the point of whole project.
  • edited January 2011
    tstih wrote: »
    5. There shall be a network support called SpecNet available via IF1 network and/or via serial port to PC. It should be possible to mount PCs HDD via serial port using some simple mounting protocol enabling ZX access to 32 bit virtual hard drive.

    Since Microdrives are reasonably rare and very unreliable, and multiple IF1 machines are not available - you should probably consider the Spectranet instead.

    Why?

    * Already has a Unix fcntl-like filesystem abstraction layer.
    * Already has a BSD style socket library which works with TCP and UDP
    * Has the common network of today (10/100 ethernet)
    * Fast
    * Just about to go into production :-)

    In particular the filesystem layer isn't just for network filesystems, filesystems for local devices can be written, and you could even write a devfs if you really wanted.

    It's also a Free open source project.

    More information - http://spectrum.alioth.net/doc
    YouTube videos - http://www.youtube.com/74HC138 (you'll have to dig them out of the bar on the right, I don't have enough time to post them individually right now)
  • edited January 2011
    I can provide you with a cut-down version of Fuse which will run on a real Spectrum

    Why, Dr Kendall - I do believe you've made a joke ;-)

    D.
  • edited January 2011
    Dunny wrote: »
    Why, Dr Kendall - I do believe you've made a joke ;-)

    D.
    He should do stand up...
    I wanna tell you a story 'bout a woman I know...
  • edited January 2011
    Dunny wrote: »
    Why, Dr Kendall - I do believe you've made a joke ;-)

    Looks like Derek stole my thunder a mere... 13 years ago though!
  • edited January 2011
    Fikee wrote: »
    you are alone... honestly, im missing the point of whole project.

    Like all 8 bit retro projects, the point of the whole project is that it's fun. If someone enjoys doing it, then it's met its goals.
  • edited January 2011
    To the original poster:

    As you can see, when a new man comes to a forum and in his first post writes that he would like to create Windows, Linux or World of Warcraft, he shouldn't expect that anybody will be entusiastic about it.

    If you want to build a team, you should prove that you are a competent guy first. Write something for Spectrum. Show your skills.

    If you ask me, you can begin with some game :smile:
  • edited January 2011
    Ralf wrote: »
    To the original poster:

    As you can see, when a new man comes to a forum and in his first post writes that he would like to create Windows, Linux or World of Warcraft, he shouldn't expect that anybody will be entusiastic about it.

    If you want to build a team, you should prove that you are a competent guy first. Write something for Spectrum. Show your skills.

    If you ask me, you can begin with some game :smile:

    Agreed. A game would be a good starting point. Even something really simple might be proof enough that you are serious, and to gain favour from the speccy community.
  • edited January 2011
    Actually, if this guy is for real (which frankly I doubt...) and interested in system software, I'd be more inclined to suggest working on software support for recent hardware projects like DivIDE, Spectranet, SIF and so on - which will yield results quicker, and be of real practical use to a decent number of people (unlike something based around microdrives and IF1 networking).
  • edited January 2011
    yeah journal, day 1:

    Searched for assembler for good part of the day. A wonderful person ported binutils to Z80. It is called binutils-z80. It helped a lot since it is industry strenght assembler and a well known environment to start with. Here are my Makefile, my link script and my crt0.s file. The code doesn't do much. It sets border and paper to black and ink to light green (because it is unix - anything else would be just wrong). Then it enters IM1 to have 50Hz interrupt executing my executive (doing task switch one day).

    I used fuse and set my own rom to run it. It works.

    Next thing I need is memory manager. Tomorrow I'll start playing with malloc().

    LINKER SCRIPT
    MEMORY { 
    	rom (rx) : ORIGIN = 0x0000, LENGTH = 0x4000 
    	ram (!rx) : ORIGIN = 0x6000, LENGTH = 512
    }
    
    STARTUP (crt0.o)
    
    SECTIONS
    {
    	. = 0x0000;
    	.text : {
    		*(.text) 
    		_etext = .;
    		FILL(0x00)
    		. = 0x4000;
    	} > rom
    	.data : {
    		*(.data) 
    	} > ram
    	.bss : {
    		_bss = .;
    		*(.bss)
    		_ebss = .;
    	} > ram
    }
    

    CRT0.S
    		; crt0.s
    		; zx spectrum rom startup code
    		;
    		; tomaz stih, wed jan 19 2011
    		.text		
    		.extern _bss
    		.extern _bsslen
    	
    		.org 	0x0000			; rst 0x00
    		di				; disable interrupts
    		jp	init			; init
    
    		.org	0x0008			; rst 0x08
    		reti
    
    		.org	0x0010			; rst 0x10
    		reti
    
    		.org	0x0018			; rst 0x18
    		reti
    
    		.org	0x0020			; rst 0x20
    		reti
    
    		.org	0x0028			; rst 0x28 = fp emulator
    		reti
    
    		.org	0x0030			; rst 0x30 = debugger
    		reti
    
    		.org	0x0038			; rst 0x38 = executive
    		jp	executive
    
    		.org	0x0066			; nmi interrupt
    		retn
    
    		.org	0x100
    init:		ld	sp,0xffff		; set stack pointer
    		call	zerobss			; zero out bss
    		call	cls			; clear screen
    		
    		im	1			; im 1
    		ei				; enable interrupts
    
    halt:		halt				; halt
    		jr	halt
    
    executive:	ei				; enable next interrupt
    		reti
    
    zerobss:	ld	hl,_bss			; bss to hl
    		ld	bc,_ebss		; end of bss to bc
    loop:		ld 	a,h			
    		sub	b			
    		jr	nz, next		; if h<>b go to next
    		ld	a,l
    		sub	c
    		jr	z, end			; if l=c goto end
    next:		ld	(hl),0x00		; zero -> (hl)
    		inc	hl			; increase hl
    		jr	loop			; and loop		
    end:		ret
    
    cls:		xor	a			; a = 0 
    		out 	(254),a			; black border
    		ld	hl,0x4000		; vmem start
    		ld	(hl),a
    		ld	de,0x4001		; to
    		ld      bc,6144			; vram size
    		ldir				; all to 0
    		ld	(hl),0x44		; lt green on black cause its unix
    		ld	bc,768
    		ldir
    		ret
    

    MAKEFILE
    OBJS		=	crt0.o
    CC		=	
    AS		=	/usr/bin/z80-unknown-coff-as
    LD		=	/usr/bin/z80-unknown-coff-ld
    LIB		=	/usr/bin/z80-unknown-coff-ar
    LIBFLAGS	=	
    CFLAGS		=	
    ASFLAGS		=	
    LDFLAGS		=	--oformat binary -Map 48.map --script 48.lnk
    
    .PHONY:		all clean
    
    all:		48.rom
    
    48.rom:		crt0.o 48.lnk $(OBJS) 
    		$(LD) $(LDFLAGS) --output 48.rom $(OBJS)
    		
    
    crt0.o:		crt0.s
    		$(AS) $(ASFLAGS) -o crt0.o crt0.s
    
    clean:		
    		rm -f *~ a.out *.o *.rom *.map
    
  • edited January 2011
    I can provide you with a cut-down version of Fuse which will run on a real Spectrum.

    So pleasant here. :smile: Don't know much about ZX yet but I know that years ago when I was a kid I used to do pretty much everything in assembler. Drawing. Playing music. Really didn't use much of the ZX ROM routines. Perhaps keyboard code. Frankly, I think placing BASIC into ROM was a waste - it ate most of perfectly good 16K and was almost not used by professional software. Only as a loader for machine code.

    So here's my question to someone with better insight (then me) who offered to port Fuse and everyone read it. ;) ;) How much of ROM routines do Spectrum games really use? The way I understand it (and I only just begun with my research) tape files are memory dumps with register state (something like the task switch I'm hoping to do if CPU speed permits). I suppose these snapshots were made after basic code already run? Theoretically ... and I can't emphasize theoretically strong enough ... if I could place emulating routines on right places in ROM (accepting same registers and returning same result) and system vars too - could I have some sort of compatibility mode where most ZX games would still run under Unix even with completely different ROM?

    What do you think?
  • edited January 2011
    Get a headstart: Take a look at Uzi:

    http://www.dougbraun.com/uzi.html

    Hope that helps!...

    Good Luck! - Im all for seeing interesting operating systems on this machine!

    PS: Source code: http://www.dougbraun.com/uzi/uzi.zip

    Also check out: http://uzix.sourceforge.net/index.php?page=links&lang=us

    And: http://www.retrotechnology.com/herbs_stuff/mnix_micronix.html
  • edited January 2011
    tstih wrote: »
    How much of ROM routines do Spectrum games really use? The way I understand it (and I only just begun with my research) tape files are memory dumps with register state (something like the task switch I'm hoping to do if CPU speed permits). I suppose these snapshots were made after basic code already run? Theoretically ... and I can't emphasize theoretically strong enough ... if I could place emulating routines on right places in ROM (accepting same registers and returning same result) and system vars too - could I have some sort of compatibility mode where most ZX games would still run under Unix even with completely different ROM?

    What do you think?

    Lots of rom routines get used by software, to give you an idea here's a list of the games in the WoS top 100 which (don't) work with Open82 (an open source rom implementation) http://www.zxshed.co.uk/sinclairfaq/index.php5?title=Open82#Game_compatibility

    you'll notice that most of them are crashing because of routines that aren't done.
    My rubbish website including the redrawn Amstrad schematics and the new home of the Sinclair FAQ wiki.
  • edited January 2011
    guesser wrote: »
    you'll notice that most of them are crashing because of routines that aren't done.

    That list is based on loading them from tape, though - you'd probably find the success rate considerably higher when loading from snapshots.
  • edited January 2011
    I remember seeing a lot of people who arrived with new ideals, long posts and great ideas to make the spectrum world a better place, only to disappear after a while without contributing anything. :p Also, it looks like a lot of people arrive full of energy but don't catch up in regards to the latest Speccy stuff (hardware, software, games, etc.). It also looks like short-lived enthusiasm or temporary nostalgia for old computers makes people join the forum, create "exciting" new topics without realizing those topics were already discussed to death. :p

    I'm all for seeing new stuff for the Speccy, but I would rather see what we need the most right now: support for the latest hardware.

    I think I remember reading a topic similar to this one, but it may have been about Linux or CP/M, or both.

    If the Spectrum boots to an alternate operating system (and considering the headaches people have been having with open82), what type of things could be done with it? All programs which require Sinclair Basic wouldn't run, and all programs which use the Spectrum ROM wouldn't run either. What would be the use for it?

    I see the author does appear to be genuinely interested in making this happen. If that's the case and you're having fun, that's what matters.
  • edited January 2011
    If you are serious about this, don't limit yourself to the 48k spectrum and a 64k memory model. Write it for a general z80 target but keep the 48k spectrum in the corner of your eye while doing the implementation. There is a much larger audience for a general z80 implementation and tbh 48k ram is very tight for what you want to do. It is much better to design with ambition and reduce for a realisitic target than begin by building in assumptions of too small for this, too slow for that. Most 8-bit projects are crippled because the implementer begain with low expectations and only achieved modest results.

    The microdrive, tap, if1 interface are very limited peripherals and won't play well with a multitasked operating system. As winston says, you are much better off aiming for the modern addons: spectranet (networking), divIDE (sd cards, hard drives), etc. It's fine if you want to support the microdrives, etc, but if your implementation assumes the target peripherals are limited as in the original zx peripherals, your end product will be a 'modest result' :-) Aim for modern peripjerals and accomodate the limited ones if you want to. Think tcp/ip sockets, multiple mass storage devices (FAT32), interrupt driven (and polled) peripherals, etc.

    Lastly, keep your project modular instead of monolithic. A lot of the pieces of what you want to do has already been done or is actively being worked on. A greater contribution would be made if you worked on those pieces in cooperation with the existing scene and then putting it all together for your own end project.

    **************
    Objectives:

    "
    1. Most important parts of operating system should fit to 16Kb ROM so that I can replace (extend) original speccy ROM. Here are my initial thoughts about what I should put there:
    "

    A lot can be done in 16k. It's possible the code portion of what you want to do may be able to fit in 16kish. The data portion on the other hand....

    - start up code,
    - memory management,

    Re: malloc. This has already been tackled in the z88dk and sdcc projects.

    sdcc creates a single block from which to allocate and has a 6 byte per allocated block overhead. The algorithm is first-fit and is modified to allow O(1) freeing and efficient realloc (as in able to first attempt to expand the allocated block in place rather than do the naive malloc and copy).

    z88dk allows several heaps to exist (for example to accommodate heaps in different memory banks), with malloc allocating out of an implied 'system' heap. It also allows individual free blocks from around the memory map to be added to heap (using a somewhat misnamed sbrk) so disjoint areas can be claimed by the heap. The cost is 2 bytes overhead per allocated block and the algorithm is also first-fit. However freeing is O(n) and so is realloc. An efficient realloc is harder to implement (and hasn't been yet). However it was written this way because of the small memory space a heap operates on. The number of allocated blocks is unlikely to be large at any one time and typical allocation size is likely around 20-50 bytes (the 6 byte overhead in sdcc is significant comoared to the 2 bytes in z88dk). I am currently looking at changing the algorithm to a 4-byte overhead with even block sizes only (that's the bad news) but with O(1) free and efficient realloc with something new: a rover pointer to more evenly spread allocations throughout the heap rather than condense allocations near the start of the heap which tends to reduce performance. However I'm not sure if that is the way to go.

    Both these mallocs allocate 'near' memory, so to speak. Ie pointers from a 64k address space. The multiple heaps of z88dk still only allocate out of a 64k address space but their pointers are only valid while their corresponding memory banks are active. There is also suich a thing as a far pointer in z88dk that addresses memory in a flat 24-bit model. Far memory allocation is currently available for one target only but this model requires the compiler (C) to automatically insert bankswitch code, etc, so it is a slow means to access a flat memory model.

    Anyway this is being revisited within z88dk.


    - task manager,

    Several people have done it. There is an implementation in z88dk as well. I think it may be too heavy for my tastes but I haven't examined it in detail. One of the things you have to worry about when writing for a small memory target is you need to reuse subroutines as much as possible. This means you have to properly design software around concepts that have a lot of utility and can be efficiently implemented. A minor example is saving cpu state. A task manager needs to do this but so does an interrupt service routine. They should not be duplicating code. A more complicated example is the implementation of buffers for device drivers and a stdio library. You need to make one circular byte buffer for example and reuse the code for all drivers needing a circular buffer, not create 5 different implementations for 5 different drivers. z88dk is starting to be populated by many small utility routines because of memory concerns.

    - math functions (16 bit and 32 bit arithmetics and floating point),

    the integer stuff is mainly done with 32 bit integers typically commincated in dehl and a second operand either in the exx set or on the stack. The 32-bit multiply and 32-bit divide make use of exx and ix to keep all values in registers. sdcc has fairly good 16-bit integer arithmetic but it relies on 16-bit operations to implement its 32-bit stuff. It tries to speed up 16-bit operations by looking for special case 8-bit operands. z88dk has specialized 16 bit and 32 bit operations.

    Right now, z88dk's integer math is being split into three options: small, fast and medium. fast tries to reduce multiplier / divider sizes by 8-bits at a time and then tries to reduce loop iterations by looking for leading zeroes. It also unrolls many loops. small doesnt do much of that and relies on only a few subroutines for 8-bit, 16-bit and 32 bit arguments. medium is a compromise between speed and size.

    There is an asm 32-bit floating point implementation in z88dk now but I would like to see an IEEE single and maybe double precision implemnetation if someone has the desire and time to do one. There are open source C implementations which could be used as a guide.

    - real time clock (if possible - using IM1s 50Hz clock),
    - tty driver (or perhaps just primitives for graphics and kbd control)

    z88dk's stdio is being redone in asm and supports any kind of attached device. tty drivers are one of the things being worked on. Quite frankly, this is what slowed the release of the entire stdio library because it's a right pain in the ass to do a proper tty driver :P Be my guest if you want to write one.

    - microdrive driver
    - serial port driver
    - unix sys calls translation table and hooks into RAM (i.e. rewiring IM1 vector, etc.)
    (if any space is left I shall also include r/o ROMdisk with common tools)

    "
    2. There will be two kernels - external and internal kernel. The one in ROM will be the internal kernel. The remaining part on the microdrive shall be the external kernel (only small binary and configuration). This will enable OS upgrading without burning EPROM again (trade off is that this part will be in RAM - but it should be relatively small).
    "

    Forget the EPROM and use flash. Reflash everytime there is an upgrade.

    "
    3. Since Z80 has no MMU or superviser mode new assembler will have to be written. This assembler/linker will produce relocation table and have switches to warn programmer when he is generating dangerous code (such as HALT, IMn, EI, DI). Assembler shall be small enough to be compiled for actual ZX Spectrum.

    4. There will be tiny C compiler. Also small enough to be compiled for actual ZX Spectrum and written in std. C so that it can be cross compiled. The objective should be to be able to compile OS with this C compiler and bootstrap C compiler (compile it with itself).
    "

    Except for perhaps the assembler/linker (with fast mass storage device attached) you cannot do anything more than simple with just 48k memory. Existing cross-development tools would far exceed what you could accomplish. One day I would like to see these cross-development tools run on a native machine but it will require a large flat memory space for data (remember far pointers?) and library code that is bankswitched-memory aware. This is a long way off unless someone gets on it fulltime.

    "
    5. There shall be a network support called SpecNet available via IF1 network and/or via serial port to PC. It should be possible to mount PCs HDD via serial port using some simple mounting protocol enabling ZX access to 32 bit virtual hard drive.
    "

    Use existing hw like the spectranet which provides TCP/IP implementation in hw and atatches to ethernet and divide which allows connection to hard drives via IDE interface. Implementations of FAT32 are around in some form or another but you may want to reimplmenet if the authors built in too many 'small machine' assumptions.

    There is also a serial interface about that allows attaching connectone modules that provide wifi via AT-like commands.
  • edited January 2011
    Thats a lot of good tips there A.A...

    ..now, I guess we're all just eagerly waiting to hear about where you want to take this project tstih...?

    Im sure that if you wanted specific info or help on software or hardware that is already in develpment, or already done, then most of those responsible would be more than happy to guide and assist...

    I think most were just a little surprised and overwhelmed by the shear enormous nature of the task that you were proposing... Once you break it down, however, into bite sized pieces, Im sure you'll find people a bit more willing to take you seriously and perhaps even help...
  • edited January 2011
    yeah journal, day 2:

    Thoughts about malloc() and free() before implementing

    Since memory is in shortage on ZX Spectrum it makes sense to have "one size fits all" malloc and free.

    Meaning it should be used by the kernel to allocate necessary memory for process environment, task state, to allocate space for loading a process into memory and to allocate space for assigning a process its own stack.

    And it could be used by user software (via system calls, possibly implemented similar to IF1 calls using RST) to provide heap services to programs.

    All this space should come from the same heap above video memory. There is no possibility of protecting or isolating process memory so there is no need to complicate. If something goes wrong it will go wrong.

    Possibly there is an existing version of malloc in SDCC and/or z88dk that I will be able to use. Reinventing warm water sucks.

    Another important thing related to memory management is relocation. Here's how I imagine this could work. Imagine a highly sophisticated piece of code.

    org 0
    jp 10 ; @ address 0
    jp 20 ; @ address 3
    jp 30 ; @ address 6

    this is raw code. To create a process out of it an assembler would have to (from what I can see now - this will change as I progress)

    1) create reallocation table and put it at beginning of process executable, compile each process to address 0 (ORG 0). Like this:

    relocation table with three entries
    1
    4
    7
    and untouched code
    org 0
    jp 10
    jp 20
    jp 30

    imagine you want to load this to address 40000. You would need to walk through relocation table and add 40000 to each word at address pointed to by relocation table. So you would make sometihing like this

    LOAD 2 BYTES @ 1
    ADD 40000
    WRITE BACK

    LOAD 2 BYTES @ 4
    ADD 40000
    WRITE BACK

    LOAD 2 BYTES @ 7
    ADD 40000
    WRITE BACK

    relocation done. New jumps point to 40010, 40020 and 40030. Custom assembler is needed because it must detect normal Z80 jumps code and automatically create reallocation table (and process related stuff too).

    2) besides creating reallocation table process should also have stack attached. This means that each executable file should (possibly) have 2 bytes in the header telling about its stack expectations. The loader would then do sometihing like -

    REALLOCATE EXECUTABLE
    stack = MALLOC(STACK_SIZE)
    LD SP,stack
    JUMP TO exe_entry_point

    whee JUMP TO exe_entry_point means populating process control block with apropriate registers including PC and process will start running at next task switch.

    As for using memory larger then 48k that is an option to consider for later implementations. Also supporting ethernet and IDE seems like a great idea and should be possible if device driver environment is generic enough - however I don't know anything about complexity of this new hardware. TCP/IP stack is a huge task and being limited to 16KB...:) It will only fit if there is a good firmware inside these devices so that I could offload complexity to them. I will definitely do a check after I have first version out.

    IF1 and microdrive code is ... on the other side ... right there in the shadow rom to copy and modify a little. Though it is true that out of 6 microdrives I own three work and not the same three every time. ;) Not to mention occasional random deletion/destruction of cartridges. Luckily this does not happen in the emulators.

    After I have first version of the executive I will come to the community with something and propose to extend z88dk and/or SDCC to support the unix. Until then... :) ... after I'm through "baptism of cynism" and "i reply to this guy but i am by no means not peer pressured" there will be a "read the faq, moron" phase and then "you T-cycle waster". And only then comes the "hey man, let us crash rookies together". ;)
  • edited January 2011
    AA, couldn't sleep?

    On the nail though.
  • edited January 2011
    lol... like his sense of humour at least... ;)
  • edited January 2011
    To topic starter: try Googling for Uzix.

    No experience with it myself, but from what I understand it's an Unix-like system written for Z80 and running on MSX machines. If (somehow) you can find source code, it might be easy to port to the Spectrum.

    And judging by the description, already does a lot of things you want to do. Not that I understand the point of this project btw - there's 1001 Unix-like systems already. If YAUC (Yet Another Unix Clone) is your goal, why not contribute to one that already exists? :-? If you want to build something from scratch just for the fun of it, there's much more interesting OS'es you could create than YAUC.
  • edited January 2011
    Dunny wrote: »
    Why, Dr Kendall - I do believe you've made a joke ;-)

    D.

    We should add this joke to the FAQ, then in future we can refer people to it rather than continually having to write and re-write our own pithy and comical observations. :lol:
    Joefish
    - IONIAN-GAMES.com -
  • edited January 2011
    joefish wrote: »
    We should add this joke to the FAQ, then in future we can refer people to it rather than continually having to write and re-write our own pithy and comical observations. :lol:

    always remebering that when it gets quoted you are obliged to twiddle the end of a handlebar moustache

    ;)
  • edited January 2011
    ...you guys have lost me here... did I miss something... like a couple of years of conversation or something??? :-?
Sign In or Register to comment.