Was there any other micro with complete GUI OS in ROM ?

[ParanoidLittleMan]

Atari ST and followers came with complete (since later 1985) GUI (so with windows, icons, mouse, menus) OS in ROM . Up to Falcon. ROM size changed from 192 KB to 512 KB . That left most of RAM for user SW free.
I'm asking myself, and of course others here: was there any other with same solution ? Time period would be 1984-1994 . Apple Macintosh used to load parts of OS from floppy in RAM by need, and similar was with Amiga - loading Workbench . I really don't know other popular 16-32 machine from that time except Archimedes. Ah, the PC - it loads OS from disk, of course, from very start. Years after 1994-5 are not interesting, since OS-es became much more complex and long, so no way to supply them in ROMs.
Today: OS may be again in some kind of ROM - SSD, but writeable ' little ' faster without EPROM programmer - just as interesting notice.
So, if someone knows some - but pls. no machines with only Basic, without GUI .

[AMenard]

Acorn Archimedes I think.

[leech]

Ha, IBM Compatibles didn't even get a GUI in ROM until UEFI, and you still can't use it as an OS.

 

But yeah, the Amiga had enough basic libraries and such in it to start the system, but didn't have the UI bits which were loaded off of disk. The plus side of this was that it was easier to update the graphical parts, which I think made the ST consume more memory, if you were using desktop replacements. Would be interesting with the larger ROMs out there to get full GUI in ROM on the Amiga, or even full ROM for something in the TT with a TeraDesk or similar.

[oky2000]

There was a version of Windows on ROM for a Tandy PC in the early 90s, the only instance of Windows being in ROM on a PC I ever heard of. It was meant to be sort of like Commodore's full blown CDTV package (the one with the mouse, keyboard, disk drive as a bundle and Amiga OS on floppies). I think it was a 286, was definitely black like the CDTV and may have been Windows 286 variant.

 

I am not 100% sure it was ever released commercially despite a picture of the machine in the news section of an old magazine I read back in the 90s.

[walter_J64bit]

The A8 had GUI made late in it's life, the OS is called Diamond GOS and it's on a cart (ROM). https://www.youtube.com/watch?v=40CPFljl3fk

 

 

[MrMaddog]

There was a version of Windows on ROM for a Tandy PC in the early 90s, the only instance of Windows being in ROM on a PC I ever heard of. It was meant to be sort of like Commodore's full blown CDTV package (the one with the mouse, keyboard, disk drive as a bundle and Amiga OS on floppies). I think it was a 286, was definitely black like the CDTV and may have been Windows 286 variant.

 

I am not 100% sure it was ever released commercially despite a picture of the machine in the news section of an old magazine I read back in the 90s.

 

It was called the Tandy VIS

 

Also I believe there some PC's that had embedded Linux with a built in web browser so you didn't need to boot an OS to go online. But of course no one used it...

[Osgeld]

early mac's ... lisa, arguably tandy 1000 series with deskmate (though gui it didnt really get the graphics until later)

[ParanoidLittleMan]

Ha, IBM Compatibles didn't even get a GUI in ROM until UEFI, and you still can't use it as an OS.

 

But yeah, the Amiga had enough basic libraries and such in it to start the system, but didn't have the UI bits which were loaded off of disk. The plus side of this was that it was easier to update the graphical parts, which I think made the ST consume more memory, if you were using desktop replacements. Would be interesting with the larger ROMs out there to get full GUI in ROM on the Amiga, or even full ROM for something in the TT with a TeraDesk or similar.

As usual, every solution has it's good and bad sides. Having OS in ROM saves RAM, but is harder to upgrade. Additionally, SW must be written is special way so can run from ROM - static and dynamic parts must be separated. TerraDesk would need some rewrite to be able to run from ROM, I'm sure. Even TOS executes some shorter routines from RAM, because it would work slower from ROM.

[rpiguy9907]

Amstrad PcW16, Acorn Communicator...

[ijor]

Even TOS executes some shorter routines from RAM, because it would work slower from ROM.

 

I realize that there are special cases that routines running from RAM could recoded in a faster way (self modifying code, PC relative references to RAM). But the exact same code should never run faster than ROM, at least on a plain ST (no fast RAM, no cache). Or I miss something? On the ST (again, plain ST), ROM code might actually run faster than RAM in some cases.

[ParanoidLittleMan]

Well, I guess that code was written with running from RAM in mind, so it can not work from ROM. It needs to look better in it, but I really don't see any other reason for putting it in RAM. Maybe when will have plenty of free time ...

ROM code may run faster if there is no exact 4 cycles rule - like with dbf instructions - where needs to add 2 wait states to keep sync with video RAM .

[ijor]

ROM code may run faster if there is no exact 4 cycles rule - like with dbf instructions - where needs to add 2 wait states to keep sync with video RAM .

 

Yes, but not every occurrence of an instruction with cycles that are not multiple of four, like DBF, would benefit running from ROM. Only when more than one is performed before accessing RAM. Otherwise you gain two cycles in one instruction, but the wait states are inserted later when accessing RAM.

 

Btw, I wonder how much on the average TOS on RAM is slower because of this ROM advantage of not requiring access on a four cycles boundary. Probably not too much.

[ParanoidLittleMan]

There is plenty of dbf instructions in TOS . And it may be some others with cycle count not dividable with 4 . Probably best way is to perform accurate speed tests of diverse operations - so using some benchmark like GemBench - with same TOS v. running in ROM and RAM . I made tests with 1.04 in RAM, just need to put it in EPROM and do same. I guess that max diff will be not more than 2% .

Or maybe can do it in cycle accurate Steem ? If accuracy goes so far .

P.S. not good idea - cycle count is always multiple of 4 in Steem when runs in ROM .

Edited August 1, 2018 by ParanoidLittleMan

[ParanoidLittleMan]

I made tests with TOS 2.06 in ROM and RAM . Conclusion is that running from RAM is slower about 1% in average.

Tested with GemBench6 and QuickIndex 2.2 . Biggest diff - 3% was with VDI graphic. Usually it was 100% vs 99% , GEM dialog, GEM Window operations were with same speed - maybe just because they are executed in RAM most part even if TOS runs from ROM. And GEM Window operations are 11% faster in 2.06 than in 1.04. Of course all tests are done without using blitter.

 

Back to topic (at least partially): this difference may be higher in case of Amiga, for instance - where CPU slowdowns more than by ST - when accessing so called chip RAM (if I remember correct). By ROM access should be no slowdowns of CPU, I guess. Any Amiga expert have something to say ? Here is chance to discuss something other than which machine runs games better

[ijor]

There is plenty of dbf instructions in TOS . And it may be some others with cycle count not dividable with 4 ...

 

Yes, of course. But as I said, it doesn't always saves 2 cycles. Consider the following code:

 

   moveq #0,D0
:loop
   move D0,(A0)+   ; A0 points to RAM
   dbf  D1,loop    ; 10 cycles from ROM, 12 cycles from RAM

The DBF instruction indeed takes two cycles less from ROM. But then the MOVE instruction at the loop would write to RAM at an "unaligned" cycle. That is, it will perform a bus cycle not on an 4 cycle boundary, and this is what really matters for producing wait states on the ST. So now the MOVE instruction will get two wait state cycles. The result is that this loop takes the same from RAM or from ROM (well, the last DBF execution that doesn't loop might still take 2 cycles less depending on the code following the loop).

 

OTOH, if the loop doesn't address RAM (say, it performs a ROM checksum), then the gain at the DBF instruction is effective and each loop iteration would take 2 cycles less from ROM.

 

I made tests with TOS 2.06 in ROM and RAM . Conclusion is that running from RAM is slower about 1% in average. Tested with GemBench6 and QuickIndex 2.2 . Biggest diff - 3% was with VDI graphic.

Interesting, many thanks.

Edited August 1, 2018 by ijor

[ParanoidLittleMan]

I just looked in my TOS 1.04 disassembly (what is now complete), to have some picture how often it is used. And it is.

First occurance:

lFC00AA    move.b    #2,-$7DF6(a5)
lFC00B0    lea    -$7DC0(a5),a1
    move.w    #$F,d0
    lea    lFC068A(pc),a0
lFC00BC    move.w    (a0)+,(a1)+
    dbf    d0,lFC00BC

It accessing ROM and shifter - palette setting, so no added wait states. But that's early HW init stage. Affecting not GEM speed.

 

Better example:

lFCF9AA	add.w	d3,d2
	bcc.s	lFCF9B0
	addq.w	#1,d0
lFCF9B0	addq.w	#1,d0
	dbf	d1,lFCF9AA

Here no memory access at all.

[ijor]

It accessing ROM and shifter - palette setting, so no added wait states.

SHIFTER gets the same wait states as RAM because they are in the same data bus. So again, that loop initializing the palette won't run faster from ROM.

 

Better example:

...

Here no memory access at all.

Yes, that's a good example. Also combines two branches. So the gain when running from ROM would be significant.

[gozar]

The Mac Classic shipped with System 6 in ROM. I think it was pretty limited, but with 1MB and one floppy that ability helped it be a little more useful.

 

 

Sent from my iPhone using Tapatalk

[Casey]

Yes, as mentioned above, several of the Tandy 1000s had enough of MS-DOS and DeskMate to start up the GUI portion of DeskMate in ROM. The ROM was presented to MS-DOS as just another drive letter, but towards the end of the 1000 line, a good chunk of the GUI of DeskMate was in ROM. I do recall the Tandy 1000 RL advertising the fact that the spelling checker dictionary was also in ROM, making spell checking of documents much faster. If you launched a program in DeskMate that wasn't in ROM, it would either run it from the installed hard drive or prompt you to insert a disk for it. Definitely usable if you didn't have a hard drive.