vol

Of course, enthusiasts showed a lot of fantastic images that they could make for their beloved platforms. Some masterpieces for the Atari 800, Commodore 64, etc can't help but impress very strongly. However the article is mostly about systems that can show ANY color photo in acceptable quality on their display. The original Amiga can do this naturally.

It seems that the Amiga was the first PC capable of displaying color photos. There is an article about this that was recently published.

This thread is old but still very useful. I got the RastaConveter sources from github, tried to compile them on Linux and failed. I had to apply several patches. Let me share them, it would be great if this helps someone. linux-patch.zip

You can display a gamut that shows exactly 3200 colors on your GS. I can't agree. The problem is in the quality of the converters. Super Convert works just very badly for this. 3200 Convert is much better but it is far from perfect. I can repeat that this type of conversion requires a lot of CPU power that the IIgs can't provide. I remember that an image converter for the Amiga can work tens minutes on a modern PC! I can confirm my words with examples on the page - Super Hires conversions are much better than dithering on the Double Hires pictures. The image of the Alps there contains 253 colors. And I can again express my sadness that this great tool was not developed further. My picture for the IIgs contains 112 colors and IMHO it looks much more colorful that your dithering. Dithering is available in 3200 color mode too. I know nothing about this. It seems rather implausible for me. Could you provide a link to some material that confirms this? IMHO the video can stop the CPU when it reads the palette information each visible line but the CPU is free on the overscan area so we must have at least 30% of the CPU power for this mode. It is not too much but it is still faster than the IIc.

Let me report a few things: 1) Super Convert 4 (formerly SHRCONVERT) works rather very poorly for photos. It can only give some quality when it uses 16 colors per image. Its multi-palette conversion quality is just very bad. 2) Convert 3200 works much better for photos. It can actually use several hundred colors per image! However the IIgs power can't support complex extensive search algos. So IMHO a cross-platform converter can make better quality. 3) Cross-platform tool TOHDR often doesn't just work for unknown reasons. It's sad that the community didn't test this great utility thoroughly and didn't give proper feedback to the author. I have attached the original image and the best conversion result to this post. It would be great if somebody could get a better conversion result. It sounds just rather oddly to me. The Apple IIgs can actually show 3200 colors on an image. So it is not clear why someone would call this a misnomer.

The tohgr converter produces a preview file in the png-format so it is quite easy to check the result. I haven't still tried the tohgr results on a IIgs. However is it true that there is no a viewer?! I can only hope that if I put the image file content at $C0000 it will do the trick. I have an assumption that tohgr doesn't work if the source image has more than 16 different colors in a line.

Thank you very much. Can anyone help me a little more? I want to get a color photo on the IIgs. It seems tohgr does what I need. But it just doesn't seem to work with the -3200 option for my pictures. I tried different images and I always failed to get a proper conversion. It seems that the utility requires somehow preprocessed images and I don't know what should be preprocessed. I surfed the net about the tohdr peculiarities for the -3200 mode but I found nothing. Maybe there are other options besides tohgr to get 3200 colors?

I am curious about the controversy surrounding the IIgs graphic modes. Most sources claim that the IIgs maximum raster is 640x200 but there is also information that it is 640x400, for example, this page and this. Would anyone like to help find the truth?

@nick3092 Sorry I was in hurry and missed that you actually answered my question. Thank you very much. It is sad that I can't remove my previous post. However we have discovered a very old bug!

Thank you but please check the original code because INPUT can't help to read an arbitrary text file.

@OLD CS1 I directly mentioned DOS afore. 😉 It seems PD works without quirks - thanks to @nick3092.

@OLD CS1 Thank you very much. However I have not been able to find any mention that the READ command affects write operations or the WRITE command affects read operations. Examples in the DOS Programmer's manual show that if a file is open to read then writing to the screen must work the usual way. Moreover I can't find anywhere a kosher way to read an arbitrary text file! 🙁 Let me also add an example from page 64 of the manual 1000 GET C$: PRINT C$ ; (Read 1 character and echo it) This line reads a char from a file and echoes it on the screen... Maybe I missed something or it is just a old unfixed bug.

I am perplexed by a strange quirk. I haven't find any mention of this in any documentation. Would anyone like to help me to get any explanation of the quirk. It is about the work with text files. Let's examine my example. 10 D$=CHR$(4) 20 PRINT D$ "OPEN F1" 30 PRINT D$ "WRITE F1" 40 PRINT "HELLO WORLD!" 50 PRINT D$ "CLOSE" This program just creates a text file that has name F1. Let's read this file. 10 D$=CHR$(4) 20 PRINT D$ "OPEN F1" 30 PRINT D$ "READ F1" 40 ONERR GOTO 80 50 GET A$ 60 PRINT A$; 70 GOTO 50 80 PRINT:PRINT D$ "CLOSE" This doesn't work for me. I need to change line 60 with 60 PRINT " " A$; and this works! I have checked this on MAME and MICROM8. It seems the first printed symbol always disappears somewhere.

I have rotated a 512x424 interlaced picture that was generated by my program and got an Xmas tree! 😀 Happy Holidays for everybody!

the link 😀

Sorry, the link needs several clicks to get it from the benchmark page. You can run each program individually or run AUTOEXEC to get a menu.

I have just added results for the Geneve 9640 into my project . The Geneve shows itself very good, its results are much better than results for the Apple IIgs, IBM PC XT, or Sinclair QL. It is only slightly slower than the Amiga 500 or MSX turboR. Maybe it is possible that somebody can write more optimized code for the TMS9995 and overrun the Amiga. However the main loop is only 14 assembly instructions so this is rather unlikely. The TMS9995 also shows an excellent code density, only the DEC T-11 main loop is one instruction shorter. Sorry I was lazy to make a better palette so generated pictures look rather rawish. I can't help but compare several speed results with results of the old good Fractal 2.0 program that can generate and save very impressive images. We can compare the performance for the same Mandelbrot parameters: x in [-2.25, .75], y in [-1.24, 1.24], iterations = 37. Both programs use GRAPHIC6 (512x212, 16 colors), screenshots are below: Fractals 2.0 - about 42 minutes; Super Fast Mandelbrot Generator - about 14 seconds. The generated images are not exactly the same and don't exactly know why. It would be great if someone could run my programs on a real machine (I have to use MAME/MESS) and check several of the results with the results published in the main table of my project. Several screenshots would also be great. My programs don't use delays between using the VDP ports so it a question, can they work at all? 😄

Several good emulators for computers that are capable to display interlaced graphics (I know about the MSX2, Amiga, Commodore +4) show this graphics flawlessly. PAL systems can even get more colors using the PAL inversion trick.

Thanks for all the help. It seems all my graphical routines work perfectly now. But I am still curious about the necessity of delays when I use the VDP data port. IMHO a plain MOVB from a register needs at least 5 memory accesses and this provides all the required delay, right? BTW thanks to @9640News I have slightly examined GEME graphic routines. I have found out that it rather doesn't use direct VRAM address setting, it rather uses the VDP commands and the VDP coordinate system. I also checked XHI sources (thanks to @Torrax) - they contain a procedure to set an address in VRAM, mine procedure is similar to it. IMHO MAME/MESS has a really very good emulation of the Geneve but this emu has several irritating "features": 1) it can't release/grab the mouse - you need to use your host OS features to switch between tasks; 2) it can't show interlaced graphics properly. It is not issues of the Geneva emulation but general MAME/MESS shortcomings.

I have just found the explanation for this mystery. My routine must draw a pixel and it actually draws it but something else prevents us to note it. This else is the VDP that works in parallel with the CPU. When we call XOP to set a screen mode we get a new screen mode and the clean screen. The latter is a result of the VDP command which cleans VRAM. So when my routine puts a pixel this command is in progress and it cleans that pixel. We need to wait until the command stops and only after that do other our tricks with the VDP. I use the next code to wait until the VDP is free. VDP0 equ >F100 VDP1 equ VDP0+2 VDP2 equ VDP0+4 VDP3 equ VDP0+6 wait: li 0,>28f *>8f = >80 + 15 limi 0 movb 0,@VDP1 swpb 0 movb 0,@VDP1 mov 1,0 *delay movb @VDP1,1 li 0,>8f *>8f = >80 + 15 movb 0,@VDP1 swpb 0 movb 0,@VDP1 limi 4 andi 1,>100 jne wait

IMHO this order is not important but routines for the MSX2 always set R14 at first. Does your code work? Can you share it? BTW I have surprisingly found out that XOP @six,0 uses R6 not R4. This means that R4 and R5 are just skipped in the call - what an oddity! And this call is astonishingly slow.

I have just converted the official MSX2 code... The MSX2 uses the same VDP as the Geneve. Maybe it is an issue of the emulator? I prepared a small program which must plot several dots somewhere around the screen middle. It plots nothing when I ran it under MAME/MESS but it may work as expected on real hardware. It would be great if somebody could try this. DEF T1 T1: li 0,0 li 1,6 ;graphic mode 6, 256x212, 16 colors xop @six,0 li 0,>35 li 1,2 *sets R2 = $1f li 2,>1f *1f - page 0 xop @six,0 li 0,>18e li 1,>40 bl @sva li 0,>f5e3 movb 0,@>f100 swpb 0 movb 0,@>f100 ;write 4 sequential dots bl @getkey li 0,0 li 1,1 ;text mode 2 xop @six,0 blwp @0 sva: limi 0 ;set an address in VRAM movb 0,@>f102 ;R0l - >8e, R0h - video page swpb 0 movb 0,@>f102 nop movb 1,@>f102 ;R1l - hi addr OR >40, R1h - lo addr swpb 1 movb 1,@>f102 limi 4 b *11 getkey: li 0,4 li 1,>ff00 xop @five,0 jne getkey b *11 five data 5 six data 6 END

Thank you very much. I am going to dig into it soon. BTW are sources of FRACTALS v2.0 available anywhere? It must contain very good graphic routines too.

I am trying to do some assembly code which shows a picture but I can't find a way how to put a pixel where it needs to be placed. There is no problem when a screen mode uses less than 16 KB but what to do if it uses more? For instance, GRAPHIC4 (256x212, 16 colors) uses 26 KB, GRAPHIC5 (512x212, 16 colors) uses two times more, etc. So I need to set a graphic page number and I can't figure out how to do this. I tried to use the next code li r0,>018e *set page 1 via VDP register 14 li r1,>40 *set the address to 0 on this page limi 0 movb r0,@>f102 *R0l - >8e, R0h - video page swpb r0 movb r0,@>f102 nop movb r1,@>f102 *R1l - hi addr OR >40, R1h - lo addr swpb r1 movb r1,@>f102 limi 2 li 0,>f500 *>f5 defines 2 pixels (GRAPHIC4) movb 0,@>f100 *puts the 2 pixels at VRAM address >4000 It doesn't work but it works for page 0. I am aware about the XOP @six call but it can't handle interlaced graphics and it is rather slow. Would somebody like to help me a bit? A lot of thanks in advance. EDIT. I use the MAME/MESS emulator for my project.

Thank you. I like trs80gp very much, IMHO the idea to keep the base disks inside emulator is really fantastic. Aton CP/M has also a special call to read the system timer, this call is described in the manual (page 30 in the pdf-file). I use this call in my program. It is still interesting why Aton CP/M timing discrepancy is much larger than PT CP/M. I still have tiny doubts about this. I can't still understand how can the model II be slightly faster than the model 4p? Maybe it is because of more frequent interrupt rate under TRSDOS62? Some results from real hardware can really help me much. Anyway I am gathering timings for 100, 1000, and 3000 pi-digits computation. Under Pickles and Trout CP/M using trs80gp, I got 100 - 1.62 s 1000 - 146.65 s 3000 - 1313.34 s However we know that the emu is not 100% accurate for the model II timings...