Denial

I assumed the x's in line 5 were supposed to be y's. That's neat. Though not what I'd call random. All kinds of patterns can be done changing the values added to x and y.

GreyGhost wrote:Though not what I'd call random.

How about this? Greetings,

Michael

Cool, you're quite the matha-magician. This one definitly appears random. Does this one also only produce the same number combos once? Can you explain a little on how it works?

This is number theory. The numbers from 0 to 65536 form a field, and 75 is relative prime to 65537 (the number of elements in the field).

That means: is a sequence of numbers from 1 to 65536, which all appear exactly once (as you've guessed). The choice of the base 75 results in a seemingly random distribution. It is the same random generator that is used in the ZX81 and ZX Spectrum.

I then subtract 1 from the generated numbers to get a range from 0 to 65535, and then throw away all numbers from 30720 to 65535 as they don't correspond to pixels on the screen.

Michael

New version 4.02 of MINIGRAFIK!

- The draw commands and the point test function now also support multi-colour mode,
- @SAVE, @LOAD commands have been added for disk and tape access,
- faster start-up time (no more slow POKEing into memory from READ-DATA statements during start-up).

Edit: The executable of MINIGRAFIK is now part of the MG batch suite. The manual of MINIPAINT also contains instructions for using MG commands in your own programs.

That's a great program! But typing it in... I really should get a better way to transfer data to my VIC

I haven't had a chance to test it yet but I copied and pasted the program into Power20 and saved the result out here. That should save you some typing. Being able to paste into the VIC's BASIC editor is such a lovely feature.

Update: Michael was kind enough to send me a working copy of the program along with the loader. Both are available on a d64 at the previously provided link.

I found a bug in version 4.01, in the newly introduced @SAVE command. A typical variant of code 'optimization' gone wrong, which in that case corrupts the colour RAM information of the saved image.

The bug has been fixed in 4.02.

Michael

Thanks to Michael, version 4.02 is available from http://www.vex.net/~falco/petscii/minigrafik.zip.

This is a 3d function plot of sin(x)/x, a small type-in that I wrote back in the days of plus 4, now adapted for the VIC20:



(for the plus/4 version, click here).

Adding another 3D program for MINIGRAFIK, this is a pie chart: Line 25 contains the number of pieces.

Some questions about the MINIGRAFIK:

1) is its source code available?

2) why the odd screen size 20x24 which uses only 480 characters instead of the standard size 22x23 that uses 508 characters?

3) in your opinion, is this graphic mode suitable for developing games, like C16 and Plus4 games where there are no hardware sprites?

1) is its source code available?

Yes. You are the first one who asks for this. Currently the source code uses the inline assembler of HI BASIC, and would need some work to port to DASM.

2) why the odd screen size 20x24 which uses only 480 characters instead of the standard size 22x23 that uses 508 characters?

When doing bitmapped graphics, one usually uses double-height characters to minimize the space for the text map. So MINIGRAFIK actually only uses 240 chars to display the graphics. MINIGRAFIK is designed to be interoperable with BASIC. The lower 1K therefore cannot be used to store the text map. MINIGRAFIK stores char map and bitmap entirely in the space $1000-$1FFF.

The maximum resolution possible under these circumstances derives as follows: you need 17 bytes (1 byte in the text map, 16 bytes char definition) to display a 8x16 block. 4096/17 ~= 240,9. 240 chars nicely fit into a 20x12 grid, which gives the 160x192 (=20*8 * 12*16) resolution. Since the pixels have a rectangular shape, you'll still also get an rectangular shape of the whole display.

3) in your opinion, is this graphic mode suitable for developing games, like C16 and Plus4 games where there are no hardware sprites?

Yes. VicTragic's Parachute uses this mode. Since the bitmap is built in column-major order, the addressing is indeed even simpler, than with the hires-mode on the other CBMs.

Greetings,

Michael

Michael thank you for the replies. I've learned something I didn't knew about double height mode, namely that is spans over 4K bitmap, where normal characters use only 2k.

Now I see why everything was made the way it is.

I instead assumed that the bitmap mode was made with a raster trick, by flipping 36868 between 253 and 254 at start and middle of the page, so that characters would be read from 5120 and 6144, overcoming the 2K bitmap limit.

And, yes, I am interested in the source, I need only the screen and pointers setup part.

The VIC-I chip itself can actually address up to 16K, of which 10K is present in a real VIC-20 (4K ROM, 1K colour nybbles, 5K RAM) and the rest is unconnected address space as explored in most recent demos.

Of course a fully bitmapped screen without using raster tricks could not be bigger than 256*16 = 4K, plus some memory for screen matrix and colour matrix, but with e.g. more RAM the bitmap could be double buffered.