SOS on the //e?

5 posts / 0 new
Last post
Offline
Last seen: 1 year 11 months ago
Joined: Mar 31 2020 - 19:55
Posts: 848
SOS on the //e?

I'm curious, has anyone managed to run SOS on a //e with a large memory card? Given that we have 1MB cards commonplace, twice the RAM of the ///+, I see no system resource reason why a //e couldn't run SOS. I frankly have never tried to do that, but I would expect the boot block difference to get in the way of it working. 

 

SO, has anyone managed to run or port SOS to the //e or //gs architecture? I think that it has some advantageous features that might be useful.

dorkbert's picture
Online
Last seen: 1 hour 15 min ago
Joined: Apr 12 2009 - 16:33
Posts: 364
No, the III despite running

No, the III despite running on a 6502B has very different memory architecture.

Offline
Last seen: 1 year 11 months ago
Joined: Mar 31 2020 - 19:55
Posts: 848
dorkbert wrote:No, the III
dorkbert wrote:

No, the III despite running on a 6502B has very different memory architecture.

 

That's a shame. I would think that the memory page size and mapping could be overcome, but it's require disassembl and porting. 

 

We had one /// system, back in 1981. After a few months, we pretty much gave up hope of developing for it, and I barely remember anything of its architectural specification, as we ended up doing very little with it, and eventually installed a Titan //e card in it, using the wonderful keyboard and interfaces, plus a ProFile-10 to work on //e software.

 

I do recall liking SOS and some of the /// software, but developing anything for it, I recall being a complete disaster, and I was barely involved with that adventure. I think that I did some hardware fixes on it, as well. 

 

I took the system home with me around 1995, and it remained here until it was stolen about six years ago. 

MacFly's picture
Offline
Last seen: 2 weeks 2 hours ago
Joined: Nov 7 2019 - 13:49
Posts: 442
Timelord wrote:That's a shame
Timelord wrote:

That's a shame. I would think that the memory page size and mapping could be overcome, but it's require disassembl and porting. 

 

The Apple III had some interesting memory concepts. When using instructions with indirect memory access, and the source of the indirect address was located in a specific memory area, then the hardware logic would automatically extend the 16bit address with another 8bit taken from another memory area - which depended on the location from where the first 16bit were taken. So, the Apple III could use 24bit addresses and thus access all available memory without switching any memory pages/banks. This logic was implemented externally, since the 6502 itself only provided a 16bit address bus.Features like this are not easily ported to other machines.

 

 

Offline
Last seen: 1 year 11 months ago
Joined: Mar 31 2020 - 19:55
Posts: 848
MacFly wrote:Timelord wrote
MacFly wrote:
Timelord wrote:

That's a shame. I would think that the memory page size and mapping could be overcome, but it's require disassembly and porting. 

 

The Apple III had some interesting memory concepts. When using instructions with indirect memory access, and the source of the indirect address was located in a specific memory area, then

The question here, is: Is this in any way necessary to port some of the core featurs of SOS to say, ProDOS 2.5+?

 

One of the nice features of SOS was that it would locate files spanning multiple volumes. Some of the kind features that made SOS so rich and powerful, that ProDOS never inherited, I feel could be adapted to work within the //e page sizes, without needing address access like that. 

 

Actually, it might be an amusing project one day, if I live long-enough, to design an Apple /// HW emulation card for the Apple //e. From what i can see, the memory paging and addressing was handled by its own controller, and designing a //e card with that kind of controller isn't beyond the realm of reason. 

 

Still, I would think that the kernel itself could be ported, given enough time and people who care. Anyway, it's not an easy task an I'll leave it at that. 

 

P.S. I recall some of the memory handling being one of the complaints for developing for the ///, as well as lack of decent language support, which was very large nail in its coffin for us back in 81-2. By 1982, the writing was on the wall, which is sad, really, as the /// series could have matured into something wonderful if it wasn't strangled at eery turn. 

Log in or register to post comments