TOS ROM expansion possibilities

[ParanoidLittleMan]

Title means TOS ROM expansion, so this is not so much about expansion of TOS self, but ROM space expansion. What of course can be used for expanding TOS self (and it is done actually in case of TOS 2.06 in ST machines - 256 KB instead 192 KB) .

I started to thinking about this reading suggestions in thread about what to put in TOS 1.62 free space. And got e-mail few days ago, about this:

http://ultradev.ultrafex.de/ultraTos.html

It works by copying TOS from EPROM in high RAM, relocating it ... I talked in reply about that it's better to keep TOS in ROM address space, so it takes no RAM, and so is more compatible too.

Things are that there is space from $E00000 (TOS ROM start address by STE, Mega STE and in case of 2.06 by STs too) . Up to $FF0000 - where HW registers are.

And there are 32 pin EPROMs available, which can fill that space (2x 8 Mbit), for not much bigger price than 1 Mbit (128 KB) EPROMs, used by STE, for 2.06 .

Not full 2 MB is usable, because mentioned HW registers, but it is more than 1.9 MB, so plenty of it. With one thing to mention: it conflicts with standard IDE port address, which is at $F00000 .  Then can go on 4 Mbit EPROMs, what gives 1 Mbyte space. Or even possible to skip that area around $F00000 (like 1 KB) . And I don't think that there is much people with IDE adapters.

Of course, some additional logic is needed for it, but that's like 1 GAL, or some CPLD - cheap for sure.

 

I worked last days on ROM disk for TOS 1.62 . There can be max some 74 KB free space (after optimizations, packing RSC data), without removing  anything from TOS .

And there can put some shorter SW, runnable in usual way. I have now working Tempus and game Missile Command (C+M) adapted for ROM disk, and solved that it be Z:  instead P: - after some extra changes in TOS disk code. That's good, because P can be hard disk partition (last one, 14-th) .  Will post it later in 1.62 free space thread. 

Much bigger space for ROM disk will allow to put some larger SW, or more of it there. And of course, it can be packed. Since there is practically no SW (Except TOS self) made to run from ROM, it must be anyway copied to RAM (even TOS copies some own parts in RAM), so then why not pack it ?

For instance I squeezed Missile Command's 188 KB into 60 KB.

I guess, this can be useful rather for people without mass storage.

So, it can be in 2 32 pin EPROM or Flash EPROM chips, which may go direct in TOS ROM sockets. Plus logic for extra address space decoding - that needs to be connected to some address lines of CPU bus, and surely can be solved with 1 GAL. Surely possible to do as some board, what goes between CPU and it's socket, or some other chip - depends from model, mainboard revision. 

And it can be used as TOS switch - then some jumper would determine will it work as linear address space of larger size, or using just section on usual TOS address space.

 

[MegaSTEarian]

I would think that quite a few people are using IDE and IMHO it'd be better to keep it operational. 

 

I myself have IDE controllers for all my Atari's (Monster or Thunder for my STE/MegaSTE/TTs)   

[ParanoidLittleMan]

If ROM size is 1 MB, it conflicts not at all with IDE. Still plenty of space - can put 1x 800 KB floppy image beside TOS 1.62 .

 

If go on 2MB size, can skip IDE port address space. And here might be some adapters which use more of IDE port address space, what is 64 bytes - $FF0000-$FF003F . To save some bits/lines at address decoder. So, I guess that should skip rather some 16-64 KB area at $FF0000 .  And there is cartridge space too. 

Other solution would be to expand ROM area not in high direction, but in lower, where is much more space to 4 MB point. Of course if machine has no so called Fast RAM expansion above 4 MB. Then can have 11 MB ROM without conflict - for those happy with 4 MB RAM ?

And I even don't want to think about bank switching.

 

[Cyprian]

1MB ROM sounds quite huge, as the biggest one for the ST has 256kB

[ParanoidLittleMan]

Just to clarify: I don't want to make some new TOS (replacement), and don't want to make more serious TOS updates/improvements. That takes plenty of time, and I already did some hard things - like FAT16 improvement. Really don't see point to change significantly Desktop for instance - there are replacements for it already, over many years. So, some smaller changes, like mentioned ROM disk Z :  . 

 

I prepare at moment something what might be interesting for gamers, especially those who don't have hard disk, may have problems with floppy drive, only 512 KB RAM .  As said in 1 MB can fit beside TOS  one 800 KB  floppy image. So, there will be image with 23 games (shorter, classic ones) . I need to fix yet some 3 of them to work from ROM disk (removing highscore file access), plus by need for Desktop start.

[Goochman]

I think some suggestions from the other thread could be valid here - take some of the more popular desktop ACC's and built them into the OS:

Text editor

Simple Terminal

Calculator(Scientific?)

Network control panel(STing or such) - or build in the TCP/IP stack

 

Adding games would be nice, but most gamers taste would vary.  Just my $0.02

 

[ParanoidLittleMan]

The problem with ACCessories is that they take RAM even if aren't used. Then, what "built them into the OS" really means ? In modern OSes it is just that diverse utils are supplied as part of OS, and most of it is loaded from disk when user needs it. In RAM are only things needed for tasks which are always needed, background processes ... Even if now most of people has GB-es of RAM, and many would fit.

So, I will stay at ROMdisk. And even with it it is not so simple. Many SW will need some corrections to run from ROM.

Well, if someone insists on ACC, it can be solved by loading it from ROMdisk too - probably best to make it optional.

 

[Lynxpro]

GDOS in ROM. Like the Tramiels promised and failed to deliver [much like easy Blitter upgrades they also promised in circa 1987].

 

ATASCII.

 

A PokeyMAX driver. 

[ParanoidLittleMan]

GDOS could be interesting. Not sure what Tramiels promised, and it is about 130 KB size, mostly font definitions ( v 1.1) . PRG self is short. The good thing is that font definitions can stay in ROM, so will not use RAM space. There are some printer fonts too, driver for SMM804 - and that's something that I doubt that someone uses still, so that part rather not.   Well, to fit it in TOS ROM need to expand it to 512 KB min. What was actually done in case of TT, Falcon -  and there is some 200 KB free space in TT ROM ?  

Installer is very confusing, and will need more time to understand how it works. Some SW what can use it, for testings ?

 

Btw. Blitter upgrades were supported in case of later STs - there is place for them on motherboards. Sometimes even socket too . And, oh the miracle - blitter chip himself too

 

[Lynxpro]

13 hours ago, ParanoidLittleMan said:

GDOS could be interesting. Not sure what Tramiels promised, and it is about 130 KB size, mostly font definitions ( v 1.1) . PRG self is short. The good thing is that font definitions can stay in ROM, so will not use RAM space. There are some printer fonts too, driver for SMM804 - and that's something that I doubt that someone uses still, so that part rather not.   Well, to fit it in TOS ROM need to expand it to 512 KB min. What was actually done in case of TT, Falcon -  and there is some 200 KB free space in TT ROM ?  

Installer is very confusing, and will need more time to understand how it works. Some SW what can use it, for testings ?

 

Btw. Blitter upgrades were supported in case of later STs - there is place for them on motherboards. Sometimes even socket too . And, oh the miracle - blitter chip himself too

 

Early in the ST's life, the Tramiel's promised that once DRI finished GDOS, it would be implemented into TOS ROMs. The claim was made in Antic/STart. But it never happened. I suspect Atari Corp's lawyers concluded that it would be considered an update DRI had done and thus put TOS in Apple Legal's crosshairs. After all, Atari Corp never tried upgrading GEM with DRI code mostly because they'd have to modify the Trash Can icon and other look-and-feel features in the GUI had they done so which DRI agreed to as part of their legal settlement with Apple. 

 

It was around the same time that Atari Corp also promised easy official Blitter upgrades to the early 520STs and 1040STs once the chips were manufactured in sufficient numbers. And they never brought to market an official PCB for the early STs...

[ParanoidLittleMan]

I don't know about those promises, and would be good to link some exact quotes, articles about it.

Because there are some things in early ST design which simply prevent adding GDOS in TOS, easy upgrade of existing STs with blitter.

 

Concrete: So, designers set TOS ROM start right below HW register address space, and size is 192 KB.  I even read that first ideas were to have only 128 KB for TOS ROM. But that was big misjudgement. Actually even 192 KB was not enough, that's why they needed Line-F emulator (abandoned only at TOS 1.06, which was in 256 KB space).  Surely, ROM prices were high in 1985, so 192 KB was good for it, especially as not everything was finished then (like GDOS).  But, if they really planned GDOS, then why provided only 192 KB TOS ROM space ?

Could set simply ROM address space lower (what was done later in case of STE) . Then they were more experienced, and let enough space for later TT and Falcon TOS too ++.  Setting ROM start to 14 MB point (as in STE) would be fine in 1985 too, but what is done does not suggest that they really thought enough ahead.

 

HW expansions, upgrades: what I remember is talk that machine has everything, and there is very fast ACSI port (what was really fast for it's time) for upgrades. Yeah, there were some, but not much. And things are that without universal CPU expansion port (seen first in case of Mega ST) HW upgrades are very hard, need lot of soldering, boards, intermediate sockets, etc. With proper expansion bus on some edge connector blitter upgrade with some smaller board would be joke. Even TOS upgrades could be solved so - and in case of ROM based OS that would be especially useful.

I don't know, maybe cutting on production costs was main concern. And it worked for some 3 years. After that there were other computers with good power/price ratio.

[MegaSTEarian]

TCP/IP stack management and a way to configure NIC would be a nice addition, IMHO. NetUSBee is quite common I think so it would be good. 

 

And is it possible to add a monochrome mode emulator (or the opposite)? 

Edited February 19, 2021 by MegaSTEarian

[ParanoidLittleMan]

It is possible to add diverse SW in ROM disk. All it depends of how much people is interested for some thing(s). In any case, even so, it is not so easy, usually need to do some modifications, fixes that it work that way. Building some SW in ROM TOS is almost impossible - SW is written to work from RAM. Even TOS in ROM performs some things in RAM, after copying code or some data in RAM. And when you  start some *.PRG from Desktop, already some 90 KB RAM is used (not counting screen) . Part of it is Line-A, VDI, Desktop RSC in RAM.

 

OK, enough talk, here is something arcadish :

So, whole 24 games in 1 MB TOS ROM space (2x 27C040 or compat. EPROMs) .  TOS is 1.62, and no disk drive attached to machine.

Can be done with STs and  TOS 1.04 (reworked to new address space, where fits, like STEs $E00000). And size can be even bigger.

 

Edited February 20, 2021 by ParanoidLittleMan
link fomat

[tjlazer]

Nice!  Link to ROM?

[ParanoidLittleMan]

ROM is not  enough. Additional HW logic is needed because larger ROM size, and it is different for ST and STE .

And I'm thinking about to combine it with TOS switch for having more choice.

Would be good to read whole thread before coming with ideas. TOS size is pretty small, about 200 KB. And HW in ST, STE supports that. To use larger size EPROMs there need little HW upgrade, except programmed EPROMs self.

We just can not expect some things present in modern OS-es, which are more than 1000x times in size to fit in limited ROM space in ST.

Max ROM size can be 11 MB, as was said, but that may cost pretty much. EPROM prices are high in compare to Flash card prices considering capacity.

[ParanoidLittleMan]

On 2/19/2021 at 1:48 AM, MegaSTEarian said:

TCP/IP stack management and a way to configure NIC would be a nice addition, IMHO. NetUSBee is quite common I think so it would be good. 

 

And is it possible to add a monochrome mode emulator (or the opposite)? 

Well, I don't haveNetUSBee, and how things go this year start, will not have it .  Without it is not possible to deal with it's support.

What I saw is that some drivers for it are pretty large size (C code ?) .

Monochrome emulator is something what may be worth, but only if can solve it running fully in ROM. Will see it - I have some code, what I modded some 20 years ago.  Although, most of modern LCD monitors are capable for ST mono mode with proper cable.

Color mode emulator for monochrome ? Was something like that ever done ? I don't think so. And it would be slow if want some quality of conversion, I guess.

[MegaSTEarian]

On 2/21/2021 at 11:10 AM, ParanoidLittleMan said:

Well, I don't haveNetUSBee, and how things go this year start, will not have it .  Without it is not possible to deal with it's support.

What I saw is that some drivers for it are pretty large size (C code ?) .

Monochrome emulator is something what may be worth, but only if can solve it running fully in ROM. Will see it - I have some code, what I modded some 20 years ago.  Although, most of modern LCD monitors are capable for ST mono mode with proper cable.

Color mode emulator for monochrome ? Was something like that ever done ? I don't think so. And it would be slow if want some quality of conversion, I guess.

Cheers. I was mainly talking about the TCP/IP stack and NIC configuration rather than drivers for NetUSBee.