ParanoidLittleMan

Never heard about. Fire problem is most likely TOS version related. Will check it tomorrow.

We can speculate about what J. Tramiel had in mind. I'm even not sure that it was his job to think/decide what (kind of) SW to develop and publish. Joust was realized in 1985 by Atari. Then more in 1986. But looking it at atarimania can see that in 1986 about 4x so many games were realized for ST. There is learning time factor: you can not program game without some experience and knowledge level. And in 1985 there was big %-age of games not using TOS - oh why ? Because it was not finished, there was only small part of it in 16 KB ROM. I think that it hurt much more than delay of couple games. And Atari games were all with TOS function calls, big part was developed by Andromeda in Hungary - yeah, we can blame J.T. to save on programmers salary 🙂 Or all US TV manufacturers for doing all assembly work in Mexico . Because that, TVs appeared 2 weeks later in shops ! They used to say: power without price. But lower price in $ costed price in time 😁

http://atari.8bitchip.info/TOS/TOSdep.html There will be soon much more ..

Funny to say that Atari corp was not for publishing games for ST, while there is plenty of them published right by Atari. Maybe they just did not want that Atari ST serve for very simple games like Centipede, Pong ...

I don't think that there is any game done for "Mega STE as min spec" . At 16 MHz it is faster some 50-80% (depends from running code), so on some ST, STE it will be just slower. And we have loooot of such games, SW 🙂 Furthermore, I don't see why would someone other deal with this game for Atari ST family. This was just step in 3D shooter direction. And I would like much more to see Tomb Raider on Atari ST. Surely it is much more demanding, but some simplifications could make it work decently. After all, Atari people likes more female heroes - like top list lifetime (or better eternal) member Giana 😃

Well, I think that only thing worth to do is involving blitter in conversion of mono screen data for medium res - that's what can improve speed pretty good. And to go with my second version, what has 2 modes - see first post here.

Resolutions are now much higher. 640x400 px versus now typical 1920x1080px . So big res. is very hard to solve quality with analog technology, and that would cost a lot.

I had SM124 too, around 2004, but did not use it much. 10 years later it did not work, and was not about to fix it - had LCD solution then. Color is lower freq. Monitor need to support about 15 KHz scan rate to be able to display ST color video (old TV frequencies) .

Thanx, it served. I deactivated copy protection check, and it works fine. Don't think that there is some delayed protection - early game. WinnieD.zip Game is for kids, simple but good looking graphics. I guess that Pasti (STX) image would be good (like for atarimania) - not hard to make, just get Pasti http://pasti.fxatari.com/ If no hard disk, Flash card adapter, 1 720 KB floppy can serve for file transfer - hmm. - if there is floppy drive in PC ..

Considering that most of modern LCD/Flat screen monitors is capable of displaying Atari ST monochrome (high res.) video, with proper cable, I want to ask is SW monochrome emulation on color monitor/TV is still of interest ? It gives not so sharp pic. , of course, and causes some slowdown too (on fly conversion). And I looked about what is available. Seen only Mick West's Mono Emu, versions from 1987 and 1988. I dealt with earlier one back in time (1988), and added new mode with 400 hor. lines, what gives sharper pic and faster work, but of course only half of pic is visible at once. As user moves mouse it will change pos. of visible part. That was good in those years for some SW. The bad thing is that it is tied for old. TOS versions 1.00 and 1.02 (only 1988 v.). And even lang. of TOS must be specific. I still have sources, so can update it for all TOS versions (well, not sure about 2.06 - that might be harder), and maybe to add it as option in TOS (1.04 and 1.62). Depends of interest. About cable for Atari ST monochrome to VGA: connect GND, Hor. and vert. signal lines directly, monochrome out to all 3 - R, G, B lines parallel. I did it via 1 18 Ohm resistor to prevent overdrive. And mono sensor line to GND. I guess hardest part in it is to find Atari 13 pin video connector. It should work with monitors with VGA input. In case of TVs - not sure. My 3 years old Philips (very good for ST color) has max refresh rate of 60 Hz, so monochrome works not. Little adjusting of screen size, pos. , and will be pretty fine.

Here is it: SKATEWAR.ZIP

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.

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.

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.

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.

3DFX was leader of HW accelerated 3D in middle nineties, and there was native support for them in some games. I had their last card, don't remember exact name, maybe was 3000 in it, was with TV tuner - came here from US from one user, so NTSC tuner 🙂 But video capturing worked in PAL mode too, although pretty low res. for today standards. And then competition got stronger and stronger, and we had Nvidia and Riva. Couple years later Nvidia bought 3DFX . Reminds on Atari corp little ? Atari was leader in some things too, but development was not enough fast to survive - said in short.

Of course my post was intended to those who might have mono version of it. And to point about easiness of opening Scart conn.

Great ! And this photo is welcome - can see that cylinder like end of Scart conn., where cables getting in. User can wind it away, open plastic case, and add one cable more - there is place for it. So no tear at all.

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

Solution is simple: since Scart has stereo audio - 2 pins for it, you need to connect L and R channels from RCA jacks to those audio pins inside Scart connector, and to GND, of course. And before it disconnect mono signal from them (which is most likely connected to both L & R parallel). Everyone with little soldering skill can do it in 15 minutes. So, 2 RCA connectors and some 2 channel coax audio cable to get for it.

OK, I will work on some better fileselector. Looked what is available to see what is worth to build in. It will need couple weeks for sure. Using some existing one - I don't think that it will be easy to change that work from TOS ROM, but who knows ... Is something with sources available ?

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.

I try to adapt early Sierra game Winnie the Pooh, but can't find good release - in meaning that it's unchanged. What is available, Automation and Klapauzius releases have some changed texts at game start (done by org. crker, some Dent), and we really don't need it. So, if someone can help, very welcome 🙂

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.

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.