SymbOS network support development

[Prodatron]

Can you do a cartridge version of it, that we could install on the C4CPC? I'd be interested in having this.

Yes, I am planning to make a CPR file, which boots SymbOS from catridge. It's probably included in the 3.0 end of this year.

[Prodatron]

Now there are some more

No, hardware sprites can't be used for icons in a modern GUI, because of multiple overlapping and a more or less unlimited amount of controls in multiple windows (and why especially icons?). You can only use 2D graphic hardware accelerators (blitter) to support this (like on the MSX).
Analog joystick input sounds good, if people are still using it.
The other stuff isn't really interesting or too special for the core part of the operating system. There can be a sound daemon (for AY [CPC+MSX], DMA [CPC+], PlayCity [CPC], Dave [Enterprise], MSX Audio, MSX Music, PCM [MSX], SCC [MSX], MSXMP3, Moonsound [MSX] blabla etc. etc. - too much different sound hardware on the supported SymbOS platforms to make "one" support in the operating system - you get it? ) and a printer daemon in the future like the network daemon.

[TFM]

Yes, I am planning to make a CPR file, which boots SymbOS from catridge. It's probably included in the 3.0 end of this year.

Booting from Cart will not leave much RAM for an not expanded (RAM) 6128 Plus (not to mention the 464 Plus at all). Shouldn't be that hard to keep some parts in ROM (and run them there), while other parts (containing self modifying code f.e.) run in RAM (you get it?). 

[Prodatron]

The memory model of SymbOS is very CPC specific, it has been designed in a way, that it fully uses the ram-based bankswitching capabilities of the Amstrad. But the Amstrad CPCs type of memory mapping is more primitive than these of the MSX/PCW/EP, which have the typical 100% flexible 4x16K out or 256x16K block switching you know from later Z80 machines (Amstrad NCxx0 as well). That's one of several reasons why it is possible to port SymbOS to other platforms. If SymbOS would have been developed on the MSX or PCW with their advanced memory banking it would be impossible to port it to the CPC. But in its "limited" CPC-way it's still providing full 64K ram areas when executing applications (so they can have a full 64K area to play with directly + anything else indirectly) while the kernel and the core manager modules can access all parts of the ram in a very fast way.
A rom based version would be possible but break up all this stuff. A lot of (currently platform-independant) kernel code would have to be modified, and you will have to maintain two different versions. I was never interested in a rom-based version, as one of the proposition of SymbOS is to run on an unexpanded computer from all supported platforms with 128K and disc drive, but a rom based version would ALWAYS require an expansion/additional hardware which is uncool, when you want to show, that such a system works at least (in a limited way regarding the number of apps running at the same time) on the original hardware. Get the original computer without anything, insert a disc and just go! Another issue of a rom-based version is the fact, that the task scheduler (multitasking) would have to do some more work and handling data when doing task content switching if beside the switched ram there are roms mapped-in, too, and IMHO content switching can't be as fast as possible.

[Singaja]

Out of curiosity, would a MSX/PCW/EP specific approach offer benefits for these platforms? Would the approach be the same for all of them? I don't have that great knowledge on Z80 advanced low level programming, but find the topic really interesting :-) Still I'm really happy the CPC is the common denominator under given circumstances.

[Prodatron]

Out of curiosity, would a MSX/PCW/EP specific approach offer benefits for these platforms? Would the approach be the same for all of them? I don't have that great knowledge on Z80 advanced low level programming, but find the topic really interesting :-) Still I'm really happy the CPC is the common denominator under given circumstances.

Yes, on MSX/PCW/EP or NCxxx, the applications would be able to do bankswitching inside "their" 64K address content. So they could access more memory in a fast way. This is not possible on the CPC, as extended parts of the ram (16K) can only be mapped together with the ram from the first 64K.
So in SymbOS all operating system parts (which have to access the whole available memory in a fast way) are placed in the first 64K, as here you can switch single portions of all the extended ram. Applications are placed in secondary 64K banks, which then will be switched at once in the visible address area of the Z80.
It's not possible to use the advanced memory features on the MSX etc. without writing a completely new kernel and designing a completely different memory model, which then wouldn't work for the CPC at all. So yes, it was really good luck that the CPC was the platform where it started

And even the CPC is already advanced regarding memory banking compared to other 8bit systems. Most are more limited (ZX Spectrum, Memotech MTX, Atari 8bit, even the C128; ...and the C64 doesn't have standard ram banking at all).

FlashJazzCat is working on a very interesting project similiar to SymbOS for the Atari8bit computers:
GUI | Atari8
On this system, only 16K of an application can be switched into the visible 64K area at once, so the challenge for developing apps is even higher here, but FlashJazzCat already proved, that it's still possible (you will recognize some similarities ):



So I think we can already be very happy with the "limited" banking capabilities of the CPC

[TFM]

Well @Prodatron you got one good point when you say that you would require to split into a RAM and a ROM version. That is a lot of work, especially since you stated that you intend to release a newer version this year.
About the memory paging, I don't think it's a problem to page ROM instead of RAM, but nobody can ask you for a major rewrite, while you can use your time in a better way. It was just a thought I had. 


It's great that SymbOS runs on an unexpanded CPC to show off it's capabilities. 

[Singaja]

What about Spectrum +3? Didn't people in Amstrad do the memory bank switching & handling in a similar manner to CPC?

[TFM]

At least there seem to be a big Spectrum community. Can the Speccy do Symbos?

[Prodatron]

What about Spectrum +3? Didn't people in Amstrad do the memory bank switching & handling in a similar manner to CPC?

Unfortunately not.
128K ZX Spectrum Technical Information
Scroll down to "ZX Spectrum +2A / +3". It's still quite limited compared to the CPC (and fixed to 128K).

[Prodatron]

while you can use your time in a better way.

Yes, I use it for Z80 coding instead of starting nasty and pointless threads.

[TFM]

Yes, I use it for Z80 coding instead of starting nasty and pointless threads.

Actually no, you just keep on bitching at me. And sadly on lower level.


In this thread you're pointing at somebody is interested in SF2 and software running on it. But if there is the smallest critics on your symbos, you take it personal. Instead you should be a bit more mature and see that this review actually provides valuable information to you. Any critics is good critics. And truly you gave me tons of shit since 2007 - I took it positive and thanks to you FutureOS got better. Thank you (no pun intended). So maybe you can stop your bitching at me and don't make me personally responsible if there is one person out there who didn't sign up in your religion. Are we ok now? I hope so.

[MacDeath]

please guys, the hall of shame is already full of this...

[Gryzor]

Agreed. So... Hush.

[Prodatron]

Actually no, you just keep on bitching at me.

You call the following "bitching at you"?...:

English Cartridge with FutureOS for 6128 Plus using Plus features
BFS16 & FAT in the same HD?

The first one was only a simple question! Maybe there is already an IDE rom available. I couldn't find one, and it's your definition of the so called spartan bit to hide all the non working buttons. Not a big thing at all, but it seems that it made you very angry, and I don't know why.
The second one is a reaction on your behaviour in the CPCWiki to mark ONE software as "abandonware" - very probably because you see it as a competitor, while 99% of all other CPC software is abandonware, too, so very senseless. This is bitching. And this is too obviouse.

So what's about the bitching at you?

[TFM]

You are so cool in getting 10.5 years old stories out of the bin just to put shit at somebody.


I didn't answer lots of your post, because I'm sick an tired of OS wars.


I take a break now of everything SymbOS and you.

[Prodatron]

I take a break now of everything SymbOS and you.

That would be fantastic, I appreciate this a lot.

[TFM]

That would be fantastic, I appreciate this a lot.

Great! Just do the same thing for me! 

[Prodatron]

About two month ago all the base network routines (TCP, UDP, DNS) were working, but then the next part was the so called network daemon, which runs as a service and provides networking for multiple applications at the same time inside the multitasking environment. Defining the message based API and implementing the base structure for it unfortunately took more time than expected (I was very lazy in between ), but now it's nearly finished. NSLOOKUP already works but the best thing is: Trebmint already started the support in Unify!
So here you see the first network app coded 100% in Unify (formerly SymStudio/SymBasic) running successful:
[attachimg=1]
Like the whole Unify programming structure the code for handling network connections is object oriented, so you will have a lot of fun with the modern and comfortable way of programming

[ronaldo]

Absolutely Amazing, man. I'm looking forward to running symbos on my real CPC and start working on networked applications .

[Apollo]

This is indeed impressive and as far as I know the first CPC IP4 network stack made, is that right?

[rpalmer]

Apollo,

I had created a TCP/IP V4 stack in ROM from similar code for CPCIP.

It has support for socket programming (8 sockets) which can allow for DNS lookup. It also has supporft for DHCP and ARP for those who know what they are.

The ROM also includes scope for various devices to be used (of which i used a CS8900 chip). It is possibel to use the WizNet 5100 series chip.

There is alot the TCP/IP ROM can do, but it has been on the back buner for some time while the CPC Web Browser continue to evolve. The curret developmentr build does have a module to allow for custom network connection and this is under development.

rpalmer

[Prodatron]

This is indeed impressive and as far as I know the first CPC IP4 network stack made, is that right?

I knew from CPCIP (TCP/IP software implemenation), Dr.Zeds SYMBiFACE 3 prototype (hardware implementation - never released) and Octoates ESP8266 module for the minibooster (hardware implementation) so far, which were/are fully working. I am quite interested in Rays hardware solution as well.
The low level layer of the network daemon can be easily exchanged with different hardware drivers or a software implementation. There is currently a driver for the W5100 hardware for the MSX (DenYoNet) and a possible W5100 implementation (port based; not tested yet, not sure if this project will be finished) for the CPC available. As soon as the ESP8266 module is fully specified (it's still possible to optimize the communication with the CPC), we can have a driver here, too.

[Trebmint]

It seems networking is fairly painless to implement into Unify too. Very painless given that I don't own hardware and no emu's currently support networking (yet I hope - Please Richard Winape needs this!) I'm looking forward to localhost implementation though.

[mahlemiut]

MESS supports networking via TAP/TUN devices (Linux) or PCAP (everything else), but lacks emulation of the networking chipsets mentioned here (as far as I know, that is).