** New Frontiers in VIC-Hires-Graphics, Part 10

[e5frog]

Impressive!!

Now I'd like to see some larger pictures as well.

[matsondawson]

Has anyone with a UIEC got it working?
I've tried the fast version and normal version, but both seem to hang at random points in the render.

[tokra]

I have an uIEC and an SD2IEC as well and both stop at random times during rendering. I've had the same problem with other programs as well and also on the C128. This is not the first time I've seen this problem. I suppose it's an incompatibility of the SD2IEC-software that doesn't work correctly with sequential file reading using GET# and such.

I've had success when using SJLOAD but maybe that's because it's faster and the error would show there eventually as well. Would be nice to hear from someone using a REAL 1541.

The only other option to work around this incompatiblity is to load the extra files not with GET# byte by byte, but just load them to a fixed memory address with the standard load routines and copy the VALUES from there with the correct PEEKs and POKEs. This is left as an exercise to the reader

[Mike]

I was thinking the same thing in regards to a BASIC extension. It's really cool to see pictures in this mode, but I can't wrap my head around too many uses for a FLI mode outside of demo effects and, again, pictures. Don't get me wrong, having pictures is certainly a great achievement itself.

Of course FLI minimizes attribute clash as far as the display generation of the VIC chip is concerned.

A new BASIC extension tailored to this mode would allow for seamless access to the enhanced colour resolution by just updating the 8x1 cell which corresponds to the pixel set operation. MINIGRAFIK does the update, too, but always affects a 8x16 pixel cell.

As for an editor, I agree that it wouldn't be utilized enough to warrant the time investment to create it. It'd be cool to see one in a few years, but it's definitely not a pressing matter and I'm not implying you'd be responsible for making it. [...] More likely would be the case where the graphician would convert an image drawn in the VIC's palette and finish by touching up by hand.

With the 160x192 bitmap, there's an all-round package available: the mode itself, essentially provided by hardware, then MINIGRAFIK as a small BASIC extension, MINIPAINT as full-fledged editor, and the PGM IMPORT tools.

The latter ones allow to draw a picture sketch on paper, scan it with a PC, and import it as B/W picture into the VIC. And then fill in the colour within MINIPAINT. That's how I did the Smurf and Ghostbusters logo. More like a layman's approach to drawing pictures, though. I'd like to have the same toolset available for this new (possibly width-extended) FLI-mode, too.

As for responsibility: as I wrote elsewhere, programming and doing other things on the VIC-20 is (and IMO only should be) a spare-time activity. That there are still other people around on this planet which share this hobby around the VIC-20 is a big plus.

Maybe a lot of MINIGRAFIK pictures haven't been published, but MINIPAINT is easily my most used Commodore program and I am very grateful for your work on it. I even have an icon for it on my desktop! And I don't have many icons. If anything I made was any good there would be a great deal more pictures published. I have to believe the same goes for other people.

And I am quite eager to see the results, when Castle Rex is finished.

Pretty fruit! I think that's my favorite of the pictures I've seen so far despite the omission of inline splits. So colorful!

Extending the screen width from 9 to 26 columns seemingly doesn't impact the quality of the results that much. It looks as if the foreground colour provides the "main" colour for each 8x1 cell, the 3 global colours still cover pre-dominant colours for each line, and if the errors get too large, they are compensated by deferring them to the next line.

Including in-line splits also complicates the converter a lot, as it is not possible to change both background/border and auxiliary register at once. This introduces an additional "coupling" between neighboring colour cells. And greatly expands the search space, so keeping the conversion method then would take hours or days instead of ~1 minute on a current PC.

Now I'd like to see some larger pictures as well.

Well 208x256 practically fills the whole display area of the PAL VIC-20.




I would not post these examples, if I were not convinced about the feasibility of my approach of extending the screen width, BTW.

It's more a matter of free time implementing this.

...

Too bad there are those difficulties with uIEC/SD2IEC access. Since even simple BASIC programs are affected, these issues should be reported to the firmware maintainers.

[e5frog]

I'd love to see it - looks great!

[tokra]

Including in-line splits also complicates the converter a lot

Also remember that in-line splits won't adhere to the char boundaries but will happen a little later.

Too bad there are those difficulties with uIEC/SD2IEC access. Since even simple BASIC programs are affected, these issues should be reported to the firmware maintainers.

I did some tests with the C128 in FAST and SLOW mode and in C64 mode today. With none of the these the BASIC-program hung, just on the VIC but with both SD2IEC and uIEC. I also tried the "UI+" command to switch the devices to VIC-20-timing but to no avail. However whenever I use SJLOAD the problem does not show. I must admit I didn't do to many tries with SJLOAD though. It's a good idea anyways to use JiffyDOS or SJLOAD with the SD2IEC-devices and I'm not sure how to reach the SD2IEC-firmware coder(s) nor if they have a VIC-20 to test and debug this.

[Mike]

Also remember that in-line splits won't adhere to the char boundaries but will happen a little later.

That's another peculiarity of the video signal circuitry within the VIC chip which would of course need to be honoured.

Though, I doubt adding these degrees of freedom enhances the quality of the result that much. At least not to justify a conversion time longer by more than two orders of magnitude.

The "main" foreground colour is changed every 8 pixels. This allows access to all primary and secondary colours. Even if only white and black were taken as only two extra colours, this would already span the whole RGB cube!

But the converter has even more colours to choose from - I found some regularities though: Orange, Light Orange, Light Red, and Light Blue quite often appear as background and auxiliary colours. And the border colour is almost never chosen as Red or Purple.

However whenever I use SJLOAD the problem does not show.

The later revisions of SJLOAD feature extra routines to handle file access via the kernal vectors of OPEN, CHKIN, CHKOUT, CHRIN, CHROUT, CLRCHN, and CLOSE. And those routines seemingly can cope better with the CHKIN, CHRIN and CLRCHN single-byte access pattern of GET#.

[Wilson]

The latter ones allow to draw a picture sketch on paper, scan it with a PC, and import it as B/W picture into the VIC. And then fill in the colour within MINIPAINT. That's how I did the Smurf and Ghostbusters logo.

It seems I owe you more credit for those pictures; I always thought they were conversions filled within MINIPAINT. At least for simple pictures, your method seems like an ideal way to work for me too. Well, if I owned a scanner it would be.

And I am quite eager to see the results, when Castle Rex is finished.

Extending the screen width from 9 to 26 columns seemingly doesn't impact the quality of the results that much. It looks as if the foreground colour provides the "main" colour for each 8x1 cell, the 3 global colours still cover pre-dominant colours for each line, and if the errors get too large, they are compensated by deferring them to the next line.

Ah, that makes sense.

Including in-line splits also complicates the converter a lot, as it is not possible to change both background/border and auxiliary register at once. This introduces an additional "coupling" between neighboring colour cells. And greatly expands the search space, so keeping the conversion method then would take hours or days instead of ~1 minute on a current PC.

Wow! I see what you meant when you said this wouldn't have been possible without modern technology now.

[Mike]

At least for simple pictures, your method seems like an ideal way to work for me too. Well, if I owned a scanner it would be.

It need not be a scanner. A cheap digital camera would work as well.

But if you look at pictures like saehn's RoQ3 splash screen, Mermaid's Flower picture, or ptoing's Skeleton, you could quite as well believe a C64 is displaying those, as if there were no apparent limitation with the 8x16 attributes, and "only" 3 global colours. For this reason, I wouldn't regard the standard 160x192 resolution obsolete. That also has the big advantage of leaving 100% CPU available to the user program.

I see what you meant when you said this wouldn't have been possible without modern technology now.

Or put it round the other way: as it works now, the converter could quite easily be implemented on the VIC-20 itself, it doesn't need much memory to run - only one line of the original picture must be kept in RAM during conversion. But the run time would range from several weeks up to two years depending on whether it was coded in ML or BASIC.

[GreyGhost]

I have been following this tread as it has been progressing and I have to say that this is AMAZING!! I can't believe the pictures above are on a Vic 20. You guys are true pioneers.

Orion70, It's time for a new version of The Great Adventure, eh.

[tlr]

Well 208x256 practically fills the whole display area of the PAL VIC-20.




I would not post these examples, if I were not convinced about the feasibility of my approach of extending the screen width, BTW.

Impressive conversion quality Mike!

I can see potential ways to do this with static screens and some limitations.
Will your fullscreen idea allow arbitrary 8x1 attributes?

Btw: The fcbpaint editor was written in a somewhat scalable manner. With some work it might be feasible to implement other formats.

I already planned to add picasso with colors per line and things like that.

Time has fallen short though. :/

[tlr]

Too bad there are those difficulties with uIEC/SD2IEC access. Since even simple BASIC programs are affected, these issues should be reported to the firmware maintainers.

I did some tests with the C128 in FAST and SLOW mode and in C64 mode today. With none of the these the BASIC-program hung, just on the VIC but with both SD2IEC and uIEC. I also tried the "UI+" command to switch the devices to VIC-20-timing but to no avail. However whenever I use SJLOAD the problem does not show. I must admit I didn't do to many tries with SJLOAD though. It's a good idea anyways to use JiffyDOS or SJLOAD with the SD2IEC-devices and I'm not sure how to reach the SD2IEC-firmware coder(s) nor if they have a VIC-20 to test and debug this.

Does it work with a Commodore IEC device then?

IIRC null bytes cannot be GET# on a VIC-20. I had to do work around this in the over5 bootstrap code by making the binary avoid any zero bytes.

[Unseen]

I suppose it's an incompatibility of the SD2IEC-software that doesn't work correctly with sequential file reading using GET# and such.

Hint: I usually don't fix bugs that I don't know about, so if people just complain about problems on random forums instead of sending me a mail those problems usually won't get fixed. This time tlr was nice enough to point me to this thread.

[Mike]

I can see potential ways to do this with static screens and some limitations. Will your fullscreen idea allow arbitrary 8x1 attributes?

Yes, any 8x1 area can have a different foreground colour and be switched between hires and multi-colour.

fcbpaint was written in a somewhat scalable manner. With some work it might be feasible to implement other formats.

I already have settled on a sensible candidate for a file format, which I'll disclose as soon as the new display system works.

I already planned to add Picasso with colors per line and things like that.

And why not for *.mg format files? MINIPAINT need not be the only editor available for this format.

...

IIRC null bytes cannot be GET# on a VIC-20.

For what matters, 0 bytes are dropped by GET# also on all other CBM BASIC variants I know. Before passing a byte from the file to ASC(), I append a CHR$(0), like in:

Code: Select all

GET#2,A$:POKE AD,ASC(A$+CHR$(0))

Hint: I usually don't fix bugs that I don't know about, so if people just complain about problems on random forums instead of sending me a mail those problems usually won't get fixed.

Thanks for taking the time! A bug fix will be greatly appreciated.

Greetings,

Michael

[tlr]

I already planned to add Picasso with colors per line and things like that.

And why not for *.mg format files? MINIPAINT need not be the only editor available for this format.

That was planned too.

IIRC null bytes cannot be GET# on a VIC-20.

For what matters, 0 bytes are dropped by GET# also on all other CBM BASIC variants I know. Before passing a byte from the file to ASC(), I append a CHR$(0), like in:

Code: Select all

GET#2,A$:POKE AD,ASC(A$+CHR$(0))

I know that. Thinking more closely about it I think the issue was that for RS-232 files GET# didn't return for null bytes. The behaviour was different on the c64.