• Please review our updated Terms and Rules here

My research about graphics of the Pro

vol.litwr said:
So you claim that the FM77AV from 1985 can show photos like the Sharp X1 turbo Z
Click to expand...
Dude, I showed you screenshots of photographs displayed on the system. Why do you come back to me with this, "you claim" stuff? Look at the screenshots and explain why they are or aren't adequate photographic reproductions for whatever your criteria are.

As for the dates you use in your blog entries, look them up. This stuff is all documented; you just need to find a few different sources to confirm that you're getting a real date and not random internet nonsense. Checking the English and Japanese Wikipedia pages for the machines in question is a good start.
 
vol.litwr said:
You made a rather controversial claim. The IBM PC CGA shows much better colors on an analog display than on an RGB one... Actually I had a Commodore but now I use emulators and they show distinct 320 color pixels
Click to expand...
As for this, I really can't be arsed to school you on how NTSC colour works. But you need to learn about that, or you can't understand 1970s and early 1980s microcomputer graphics.
 
AndrewZ said:
Do you have the rare Sun "Sidewinder" 386 workstation? I heard about it in about '89 and then it was gone. I have the Pro color graphics card but my 350 has a memory issue and is no longer stable.
Click to expand...
If that's the 486i one then no. I have tried a couple of Cyrix chips and the like but was not able to get it to run POST. Not sure why, I really should get a generic 386 motherboard and figure it out.

What I DO have is the fabled CG5 Roadracer video board (4mb of RAM and a faster RAMDAC) *and* a SunVGA board which allows you to run DOS windows with VGA graphics at full speed. Makes DOOM run fine, which is neat.

Last fired them up about a year ago, I had wired in a external 3v aaa battery pack to each NVRAM module and after changing the batteries they came up fine, the 330 and 660mb drives worked, and I could even mount one to a newer NFS server. Cool little boxes. I didn't know the root password, but was able to crack it in an hour with a modern laptop and johntheripper. Apparently 3DES is not what it used to be :)
 
@cjs It seems that you simply misunderstood me. I wrote to you about dates, not the fact. Of course a system that has 4096 free colors can display photos! Nobody disputes that.
IMHO you are confusing peculiarities of the Apple II realm with other computers. Commodore monitors use chroma-luma signals and are capable of displaying all 320 color dots per line. No one but you has made your strange complaints.
 
vol.litwr said:
IMHO you are confusing peculiarities of the Apple II realm with other computers. Commodore monitors use chroma-luma signals and are capable of displaying all 320 color dots per line. No one but you has made your strange complaints.
Click to expand...
No, I am not confusing the "peculiarities of the Apple II realm" with other computers; all computers that displayed colour via NTSC CVBS worked the same way because that's how NTSC colour works. When you say things such as:

vol.litwr said:
The IBM PC CGA shows much better colors on an analog display than on an RGB one...
Click to expand...
You don't seem to realise that those "better colours" (by which you mean, simply, more colours, better for some purposes and worse for others) were created via NTSC artifacts, with a concomitant loss of horizontal resolution(from 640 pixels across down to about 160).

And yes, the C64 was capable of separate chroma and luma, as were the Atari 400 and 800 years before it. But the majority of users of those computers did not use a monitor with separate chroma and luma inputs, and thus games and the like were generally not designed around this.
 
Hi Litwr, I have a question on Xhomer. Is the only was to transfer data to Xhomer to create floppy disk images using a physical 5.25" floppy drive? Thanks.
 
I created floppy disk images with FS RT-11 for Xhomer using my program ImageUtils. RSX FS it is somewhat more difficult (it requires the participation of, well, say, simh emulator), but it is also possible.
 
cjs said:
And yes, the C64 was capable of separate chroma and luma, as were the Atari 400 and 800 years before it. But the majority of users of those computers did not use a monitor with separate chroma and luma inputs, and thus games and the like were generally not designed around this.
Click to expand...
Let's compare two screenshots, one from a good Commodore emulator and one from real hardware.
AndrewZ said:
Hi Litwr, I have a question on Xhomer. Is the only was to transfer data to Xhomer to create floppy disk images using a physical 5.25" floppy drive? Thanks.
Click to expand...
Hi
You can use the RT11DSK utility mentioned above to work with any RT-11 disk images...
 
I'm going through the old DECUS tapes for RSX. I found a C compiler, runtime libraries, and BASIC interpreter and have posted them on Google Drive here: C Compiler, C Runtime code, BASIC interpreter. Do you think we could get these into floppy format and try them on Xhomer? I see Pascal, Algol, and Watfor Fortran compilers and some games and utilities.
 
vol.litwr said:
Mandelbrot for P/OS is ready.
Please help me to get results from real hardware. Just run the program in the benchmark mode two times with NOCALC=0 and NOCALC=1. For the Pro-380, set PRO380=1 and TWORSETS=1.
BTW P/OS gives only 16 KB for a privileged program. On the RT-11 we have about 32. And the LAND game is only available for RT-11...
Click to expand...
Hi vol.litwr. I finally found a way to transfer files electronically to my P/OS DSK image using a floppy. I transferred over MBKR.mac and pinoeis.mac and have some results, now on P/OS with the PRO 380. With PRO380=1 and TWORSETS=0, the Benchmark mode shows 47.81. With TWORSETS=1, the results are 47.26. It looks like RT-11 is about 3 seconds faster than P/OS. A few notes: First, I ran the test with a monochrome VR201 monitor. My color monitor is on another system at the moment. Interestingly, there was a vertical scroll when the images were updating. The final image was stable. The image looked better than expected on a monochrome monitor. Finally, I had to comment out code at the bottom of your file that begins with VTO. Otherwise, the linker complains about TRPROU not being defined. Yes, I had to link with /PR.

For pinoeis.mac, I got a linker error: PAB *DIAG* Seg has address overflow, allocation deleted.
 
stanp said:
Hi vol.litwr. I finally found a way to transfer files electronically to my P/OS DSK image using a floppy. I transferred over MBKR.mac and pinoeis.mac and have some results, now on P/OS with the PRO 380. With PRO380=1 and TWORSETS=0, the Benchmark mode shows 47.81. With TWORSETS=1, the results are 47.26. It looks like RT-11 is about 3 seconds faster than P/OS. A few notes: First, I ran the test with a monochrome VR201 monitor. My color monitor is on another system at the moment. Interestingly, there was a vertical scroll when the images were updating. The final image was stable. The image looked better than expected on a monochrome monitor. Finally, I had to comment out code at the bottom of your file that begins with VTO. Otherwise, the linker complains about TRPROU not being defined. Yes, I had to link with /PR.

For pinoeis.mac, I got a linker error: PAB *DIAG* Seg has address overflow, allocation deleted.
Click to expand...
Thank you very much for your interesting results. Would you like to run MBKX with NOCALC=1 and TWORSETS=1? I need this to add results to the table.
Your results, in particular show that P/OS has the larger system overhead than RT-11, it is about 6% larger.
Thanks also for the bug report. The conditional assembly condition for VT0 has been fixed.
I can't get the scrolling issue on xhomer, it works too fast for me to notice this.
The pi calculator must work and it doesn't require the /PR option. The problem seems to be MEMSZ. I don't know how to get the free available memory under RSX-11 (P/OS) so I hardcoded this value with this constant. It seems the P/OS gives us slightly less memory than RSX-11 on the 11/93 or a similar system. Just try to use a lesser value, for example 31400 works for xhomer. Perhaps it can even be slightly greater but 32500 doesn't work.
BTW it would be great if a P/OS (RSX-11) expert could show us a way to get the free available memory size under this system.
 
vol.litwr said:
Thank you very much for your interesting results. Would you like to run MBKX with NOCALC=1 and TWORSETS=1? I need this to add results to the table.
Your results, in particular show that P/OS has the larger system overhead than RT-11, it is about 6% larger.
Thanks also for the bug report. The conditional assembly condition for VT0 has been fixed.
I can't get the scrolling issue on xhomer, it works too fast for me to notice this.
The pi calculator must work and it doesn't require the /PR option. The problem seems to be MEMSZ. I don't know how to get the free available memory under RSX-11 (P/OS) so I hardcoded this value with this constant. It seems the P/OS gives us slightly less memory than RSX-11 on the 11/93 or a similar system. Just try to use a lesser value, for example 31400 works for xhomer. Perhaps it can even be slightly greater but 32500 doesn't work.
BTW it would be great if a P/OS (RSX-11) expert could show us a way to get the free available memory size under this system.
Click to expand...

The result for NOCALC=1 and TWORSETS=1 is 10.26 seconds. I fixed the scrolling issue. You had the CSR Bit 0 [4(r1)] set for 625 scanning lines. I cleared it for 525 scanning lines for my monitor. I am using the legacy monochrome monitor at the moment.

Yes, the MEMSZ size is the link problem with pinoeis.mac. I forgot you had mentioned it earlier in this thread. Thanks for attaching the line wrap utility. I'm surprised the terminal wrap command does not work in P/OS 3.2. I changed MEMSZ to 31400 and it linked without error. Max digits is 8968.

The results for PRO 280 with P/OS V3.2 are 0.89 (100), 59.73 (1000), and 518.93 (3000). A bit slower than my RT-11 results below.

pinoei0.80 - 0.8257.75505.07 - 505.08

Compare with AndrewZ's Pro 350 results:
100 - 1.14
1000 - 61.28
3000 - 520.12
 
stanp said:
The result for NOCALC=1 and TWORSETS=1 is 10.26 seconds. I fixed the scrolling issue. You had the CSR Bit 0 [4(r1)] set for 625 scanning lines. I cleared it for 525 scanning lines for my monitor. I am using the legacy monochrome monitor at the moment.

Yes, the MEMSZ size is the link problem with pinoeis.mac. I forgot you had mentioned it earlier in this thread. Thanks for attaching the line wrap utility. I'm surprised the terminal wrap command does not work in P/OS 3.2. I changed MEMSZ to 31400 and it linked without error. Max digits is 8968.

The results for PRO 280 with P/OS V3.2 are 0.89 (100), 59.73 (1000), and 518.93 (3000). A bit slower than my RT-11 results below.

pinoei0.80 - 0.8257.75505.07 - 505.08

Compare with AndrewZ's Pro 350 results:
100 - 1.14
1000 - 61.28
3000 - 520.12
Click to expand...
Thank you! The tables have been updated. It is interesting to note that the NOEIS versions on the 11/93 have almost the same results as the EIS versions on the Pro-380 and the latter is almost equal to the NOEIS versions on the Pro-350.
Would you like to run the EIS version on your Pro-380? MEMSZ=31684 should be good for P/OS.
It seems the rotated Mandelbrot would better fit to your monitor.
 
czunit said:
Thanks Al. At least I have SPSS/X imaged and up here at www.crystel.com/pro350 Take what you need.
Click to expand...
What is the DEC XT100? Is this an early version of the PRO 350? The hardware description seems to match the PRO 350. What I find interesting is that this early version seems to provide more detail in some places or it describes it a bit differently that provides further insight than the later technical volumes. For instance, the graphics registers used in this thread have a bit more description. There is even some explanation about the 960 x 240 resolution. What do the .imgs contain?

1709485772377.png
 
vol.litwr said:
Thank you! The tables have been updated. It is interesting to note that the NOEIS versions on the 11/93 have almost the same results as the EIS versions on the Pro-380 and the latter is almost equal to the NOEIS versions on the Pro-350.
Would you like to run the EIS version on your Pro-380? MEMSZ=31684 should be good for P/OS.
It seems the rotated Mandelbrot would better fit to your monitor.
Click to expand...
With MEMZ=31684, pieiss results for PRO380 with P/OS 3.2 are 0.50 (100), 23.25 (1000) and 190.20 (3000). Significantly faster.
 
Well now you need to try it with a Pro/350 and an external FPF11. You know you want to.... :)
 
You must log in or register to reply here.
Back
Top