Do you think it would be able to do something like that on c128's z80?
Here are some of the features: Feature overview
Microkernel Maximum amount of supported RAM: 1024 KB Maximum number of processes: 32 Number of different process priorities: 9 Maximum number of timers: 32 Maximum number of open messages: 64 System manager Maximum number of applications: 24 Maximum application core size: 63 KB Desktop manager Maximum number of windows: 32 Maximum number of controls per window: 1000 Maximum possible screen resolution: 16.000 × 16.000 pixel File manager Maximum hard disc size: 128 GB Maximum file size: 2 GB Maximum number of devices: 8 Maximum number of open files: 7
Isn't there another thread about this? Hmm, maybe I am thinking of another forum?
Anyway, it would be very cool to attempt. However, there would be issues...
Whatever forum post I was reading said the main problem with a C128 version would be memory management... it seems the popular Z80 version that is all the rage on 'net these days uses an MMU which can (re)map arbitrary regions of 16K RAM. The C128 can only remap 256 byte regions (pages 0 and/or 1)... and I'm not even sure this feature works in "Z80 mode". That same forum post said C128 version would not be impossible, but require a major re-write of the memory management routines.
Note that an REU can not do memory re-mapping... only memory swapping (not the same thing). As I understand it, GeoRAM does do memory re-mapping... so that may be an option... of course not many own a GeoRAM, and because I don't either, my theory could be complete crap.
Another, perhaps fatal, problem is that like most OS's, it relies on fseek() to access data on disk at random. This would require a proprietary file system (similar to GEOS/VLIR or CP/M) and need to be customized for every possible format (1541/1571/1581/FD-2000/FD-4000/CMD-HD) and would not work at all with emulated/virtual drives like MMC/uIEC/VICE-FS (well it would work at the disk-image level, but not the full disk media). Hmmm, another option would be to use REL files... but REL files are poorly supported in modern solutions (MMC, VICE, etc.)
Sorry if it sounds like am "booing" the idea... actually I think it would be really cool. (I am very curious to see how fast/slow it would run on a C128.) But I just thought I should point out some obstacles that lie in the way.
I think discussing the issues -- and more importantly finding a solution -- is a good/important first step to make SymbOS a reality for the C128.
> Note that an REU can not do memory re-mapping... only memory swapping (not the same thing). As I understand it, GeoRAM does do > memory re-mapping... so that may be an option... of course not many own a GeoRAM...
There is an engineer (who I met at last year's Maker Faire) who has a geoRAM clone prototype right now. It still needs testing.
> Another, perhaps fatal, problem is that like most OS's, it relies on fseek() to access data on disk at random. This would require > a proprietary file system (similar to GEOS/VLIR or CP/M) and need to be customized for every possible format (1541/1571/1581/FD- > 2000/FD-4000/CMD-HD)...
I say the minimum would be for the 1571 drive. Not every format has to be accessible.
A GeoRAM can’t arbitrarily remap memory. It works by swapping one 256-byte page of the expansion RAM at a time into one of the two I/O blocks ($DExx / $DFxx), I do not remember which. Which page to map in is specified by a register set in the other I/O block. Note that the GeoRAM design and implementation restrict the size of the expansion RAM to no more than 2 mebibytes.
The world’s only gsteemso
Agitator-in-chief for the Seattle Retro-Computing Society
> I'm surprised no Commodore 128/128D owners having > requested a port, or have they?
Yes, I had several requests for a C128 port. I met a guy on the VCFe in Munich 1,5 years ago who helped me to collect all necessary information about its hardware. I don't remember exactly, but maybe the MMU would make it possible to run SymbOS. Unfortunately there are several reasons, why a port doesn't make much sense: - the Z80 is clocked with 2MHz only, which is quite slow. - there is still no usable multicolour bitmap graphic mode. IIRC SymbOS would end up with 320x200x2 or 640x200x2. - there are no usable memory expansions, which provide that flexible banking SymbOS requires. They all were mostly only used as Ram discs and therefore do only provide a very limited memory mapping. That means, that SymbOS would be always limited to 128KB, which is boring.
It's exactly the same reason, why a Spectrum +2/+3 port wouldn't make that much sense. Only B/W graphics (256x192x2 colours, as there is no bitmap mode) and not more than 128K, as the existing memory expansions do not allow that what SymbOS needs as a minimium.
Somehow sad, but it also shows, which computers are really powerful ;-)) (just joking).
Thanks gsteemso for illuminating my flawed theory... so if (now) I understand correctly, GEO RAM can remap any external page -- put only to a fixed internal page ($de00 or $df00).
If I understand correctly, then GEO RAM re-mapping is about as useless as page 0/1 remapping... (because SymbOS was built on 16K remapping).
Thanks for the quote, Tokra! I agree a C128 would be much slower than a typical 4MHz Z80 (but similar to a KayPro II @ 2.5MHz). I also agree there would be no multi-color mode when using the 80-column VDC. But of course the Z80 can run at "full" 2MHz with the 40-column VIC if you really want/need multi-color. Now we are mixing apples and oranges, so I'll shut up...
The last part of Tokra's quote is about "no usable memory expansions... limited to 128K". Yes, I agree this is true for a stock machine, but if you own an REU (or similar device), then there are many possibilities...
I'm thinking we need to create a "bare bones" / "no whistles" version that would work on stock machine? According to previous (unknown forum) post, it would AT LEAST require a re-write of the memory manager (because no hardware remapping). If by some miracle (or rather, serious human effort) this actually worked, then we could consider "nice" things like multi-color video, f-seek disk access, and expanded memory...
[Edit] I am sure Tokra knows better than me, but I'm thinking you could emulate multi-color mode on VDC/80-column with interlace video... [/Edit]
Last Edit: Jan 19, 2016 3:20:32 GMT by hydrophilic: Thought of something more!
I agree the post I quoted does not go too much into technical details, but basically I think it is right. Symbos limited to 128K would be "boring" and you could not really do much with it. As I understand Symbos needs a method to more or less instantly swap 16K blocks in memory. The REU can transfer 1 byte per cycle, so it would 32768 cycles to actually swap a memory block with the on-board-memory.
The VDC itself is another bottle-neck. All data has to go through the $d600/$d601 registers. GEOS 128 is a good example of what is possible with the C128 and 80 column-mode. I wouldn't completely rule out Symbos a possiblity on the C128 but a lot of ground work would need to be done regarding memory management with the REU and graphical display with the VDC. Whether it would be fast enough needs to be seen.
P.S.:Multicolor and interlace are very different concepts, but the VDC can basically do colourful graphics without interlace using the 8x2 mode for example. I'm not sure using interlace would be a good idea for an OS that you are supposed to actually work with.
I haven't looked at the source code, so that would probably be a good idea. The other forum post I was reading said that the OS has ability for full/arbitrary code and data relocation, and it mainly used the 16K remapping for speed and simplicity. In other words, this feature is not strictly needed, but a re-write would be needed to work without it.
Agree with the VDC bottleneck, and things like GEOS show what is possible.
Now that I think, the 8x2 graphics would also allow emulated form of multi-color. I'm thinking that would require some sort of dithering function to make it work? Which would make a slow system slower. I *was* thinking the interlace method would be semi-automatic... but *now* I'm thinking if you did it on a raster-pair basis, this would require the dreaded 8x1 color cells (argh). So yeah, the interlace idea is probably not the right approach.
[Edit] I just watched the video for the first time, and I must say, holy shit! Is that thing running at 4MHz or 16MHz or what? It is hard to believe you could play an MP3 in real-time on an 8-bit at 4MHz speed... let alone multi-task with video games, a GUI, etc.
Documentation on the SymbOS website talks about memory differently. It says it reserves all the first 64K for the OS, and part of the second 64K. About half (32K) is available for apps in the second Bank, and 63K available in all remaining banks. It says that it supports shared RAM at the top 16K of each bank. From what I gather, this is customizeable (an application may, if it wants, invoke shared 16K at the top of RAM).
Well the C128 can already do shared 16K at top of RAM no problem.
The docs also say that the memory manager allocates in 256-byte chunks. In other words, page-relocation which is rather simple. It doesn't say (nor do I infer) that it is actually remapping any of those chunks of memory in hardware. The only thing I can imagine is that the shared 16K at the top of RAM may be re-mapped to an arbitrary region of another bank... hmmm...
Although the SymbOS website has downloads that include source code for many applications, I don't see a download for the source code of the OS itself. So I guess we will never know...
Maybe Mirkosoft will release his ACE operating system? A 6502 at 2MHz is comparable to 4MHz Z80, so it should run as fast, or faster, than any SmybOS port to the C128. Plus ACE supports SCPU for, umm, super speed. [/Edit]
Last Edit: Jan 22, 2016 6:30:14 GMT by hydrophilic: Searching for answers...