HAPPY NEW YEAR 2024

[MrSterlingBS]

I wish all members of the Denial Forum a Happy New Year 2024.

Attached a small MG Demo...
Because of the small speed of BASIC you should switch on the VICE emulator to maximum speed.

Best regards
Sven

New Disk.zip

(1.94 KiB) Downloaded 63 times

[Soloman]

Happy new year to you all!!
And enjoy this evening with your family and friends. Happy greetings from a windy Netherlands here. 7 hours to go still.

[chysn]

Happy new year! I didn't have any luck dragging the D64 into VICE. What memory and machine settings should be used?

[Soloman]

I wish all members of the Denial Forum a Happy New Year 2024.

Attached a small MG Demo...
Because of the small speed of BASIC you should switch on the VICE emulator to maximum speed.

Best regards
Sven

New Disk.zip

Could you look over the program again? It shows some errors, with @-characters.

[Mike]

What memory and machine settings should be used?

Could you look over the program again? It shows some errors, with @-characters.

The demo runs fine here.

As had always been the case, programs using MINIGRAFIK need at least a +8K RAM expansion.

Sven, I strongly suggest you mention the RAM requirements with your releases, even if only to avoid suchalike queries. You already did not do that with your Xmas demo. Also, the MG batch suite provides the MAKEBOOT tool, which writes a boot loader on disk (preferably as first file!) that automatically loads and inits MINIGRAFIK and then chains through to the client program, so the user does not need to load and run two programs.

...

That being said, the demo itself could probably be sped up quite a lot by factoring the trigonometric functions out of the inner loops. SIN() and COS() are slow for sure, but there's no need to recalculate them for the same angles over and over again.

[MrSterlingBS]

I wish all members of the Denial Forum a Happy New Year 2024.

Attached a small MG Demo...
Because of the small speed of BASIC you should switch on the VICE emulator to maximum speed.

Best regards
Sven

New Disk.zip

Could you look over the program again? It shows some errors, with @-characters.

First you need to load Mike‘s MiniGrafik BASIC Extension. After run the program you can load the Demo and run it.
Both of them with Load“NAME“,8

[MrSterlingBS]

What memory and machine settings should be used?

Could you look over the program again? It shows some errors, with @-characters.

The demo runs fine here.

As had always been the case, programs using MINIGRAFIK need at least a +8K RAM expansion.

Sven, I strongly suggest you mention the RAM requirements with your releases, even if only to avoid suchalike queries. You already did not do that with your Xmas demo. Also, the MG batch suite provides the MAKEBOOT tool, which writes a boot loader on disk (preferably as first file!) that automatically loads and inits MINIGRAFIK and then chains through to the client program, so the user does not need to load and run two programs.

...

That being said, the demo itself could probably be sped up quite a lot by factoring the trigonometric functions out of the inner loops. SIN() and COS() are slow for sure, but there's no need to recalculate them for the same angles over and over again.

Thanks a lot for the feedback and tips. I will change it next year.

[chysn]

Hey, got it going!

After dragging the D64 into VICE, it just restarts the VIC. There's a second step required (at least, there was for me), which was to LOAD "HNY2024",8 and to RUN that. My clue was Mike mentioning MINIGRAFIK, which needs to be installed first. I didn't know what MG meant in the original post.

It's really cool! I mean, it takes a while, but the end result is fascinating.

[Mike]

After dragging the D64 into VICE, it just restarts the VIC.

More precisely, MINIGRAFIK had been autostarted by VICE and without further preparations, MG restarts the VIC-20 - with the memory allocated for itself and for the graphics bitmap. The number of BYTES FREE shown is different.

This is fine during development of a MG client application, but a release version should be more user friendly, which is why I provided the MAKEBOOT tool. This tool accepts the file name of the client application (and also a release year that appears as the line number of the BASIC stub) and then you put 3 files on the disk, in that order: BOOT, MINIGRAFIK and the client application itself. Upon loading and running BOOT, MINIGRAFIK is loaded and initialised, but instead of returning to the startup message, BOOT then continues, by loading and starting the client application without any extra step required from the user.

It is a common complaint about BASIC extensions that "they always need to be run first before running the client program". Exactly that complaint is being taken care of by MAKEBOOT and the BOOT program it produces.

[Soloman]

What memory and machine settings should be used?

Could you look over the program again? It shows some errors, with @-characters.

The demo runs fine here.

As had always been the case, programs using MINIGRAFIK need at least a +8K RAM expansion.

Sven, I strongly suggest you mention the RAM requirements with your releases, even if only to avoid suchalike queries. You already did not do that with your Xmas demo. Also, the MG batch suite provides the MAKEBOOT tool, which writes a boot loader on disk (preferably as first file!) that automatically loads and inits MINIGRAFIK and then chains through to the client program, so the user does not need to load and run two programs.

...

That being said, the demo itself could probably be sped up quite a lot by factoring the trigonometric functions out of the inner loops. SIN() and COS() are slow for sure, but there's no need to recalculate them for the same angles over and over again.

Oh, I didn't know I had to run the first program first. And I had no extra memory.

[Mike]

Could you look over the program again? It shows some errors, with @-characters.

The demo runs fine here. [...]

Oh, I didn't know I had to run the first program first.

The @-prefixed commands you find in the demo program ("HNY2024") are exactly those of the MINIGRAFIK extension. When MG is not active, they will earn you just ?SYNTAX errors of course.

Please note: supplying the executable of MG as external file is a deliberate design choice. In case there are several client programs on disk (or possibly, a PC-hosted directory with VDrive in VICE, or a directory on a SD-Card with a SD2IEC), only one copy of MG is needed. If MG was statically linked into (read: buried within) all client programs that use it, that'd waste a lot of disk space and make MG inaccessible for potentially interested new users.

And I had no extra memory.

MINIGRAFIK requires at least a +8K RAM expansion as the entire internal RAM in the range $1000..$1FFF is reserved for use by the graphics bitmap when the extension is active.

Please check out the thread "MINIGRAFIK batch processing suite" for further details about the extension. The start post of the thread also contains a link to the manual of the flagship application for MG, MINIPAINT. The BASIC extension itself is covered in Appendix B.

[Soloman]

Could you look over the program again? It shows some errors, with @-characters.

The demo runs fine here. [...]

Oh, I didn't know I had to run the first program first.

The @-prefixed commands you find in the demo program ("HNY2024") are exactly those of the MINIGRAFIK extension. When MG is not active, they will earn you just ?SYNTAX errors of course.

I didn't know that. I never heard about MG. I still have to learn a lot.
That's why I have a question too. If you look at MG after you loaded it, you see one program line, the SYS. The ml-program starts at that address. Ok, that's clear. But suppose I write a ml-program somewhere in the 4K free BASIC-memory and I type the single BASIC program-line with the SYS that executes that ML-program. When I save on disk or tape, he only saves the SYS-line, not the ML-program. What must you do that he saves that too in one program-file with the SYS. Something with altering the memory address 45,46 (start variables) where you poke in the address where the ML-program ends?

[Mike]

What must you do that he saves that too in one program-file with the SYS[?] Something with altering the memory address 45,46 (start variables) where you poke in the address where the ML-program ends?

Normally, you create such a BASIC stub from within assembler source code, with a few .BYTE directives or the like.

If you use a monitor, you need to adjust 45/46 to the first free address after the whole program by yourself. Alternatively, you can store the machine code part away, reset the VIC-20, type in the BASIC stub manually and finally let LOAD"...",8,1 adjust the pointer in 45/46 for you. I demonstrate that method in my VICMON primer thread, for the translation of the game "Killer Comet" to machine language (see end of the post where I add "2020 SYS 4352").

[Soloman]

What must you do that he saves that too in one program-file with the SYS[?] Something with altering the memory address 45,46 (start variables) where you poke in the address where the ML-program ends?

Normally, you create such a BASIC stub from within assembler source code, with a few .BYTE directives or the like.

If you use a monitor, you need to adjust 45/46 to the first free address after the whole program by yourself. Alternatively, you can store the machine code part away, reset the VIC-20, type in the BASIC stub manually and finally let LOAD"...",8,1 adjust the pointer in 45/46 for you. I demonstrate that method in my VICMON primer thread, for the translation of the game Killer Comet to machine language (see end of the post where I add "2020 SYS 4352").

Ah, the first option is type the bytes for the BASIC-line in the monitor according the storing-rules of a Basic-program in the memory, then adjust 45 and 46 and then save the ml-program including the bytes for the single BASIC-line in the monitor.
I will look up you VICMON primer-thread.

[Mike]

Ah, the first option is type the bytes for the BASIC-line in the monitor according the storing-rules of a Basic-program in the memory, then adjust 45 and 46 and then save the ml-program including the bytes for the single BASIC-line in the monitor.

If you create the BASIC stub entirely within a monitor, there is no need to adjust 45/46: you would anyhow want to save the whole file with the S command of the monitor, and then the whole program is stored.

Please note VICMON has the ugly habit of messing up the workspace of the BASIC interpreter. It is specifically for this reason I reset the VIC-20 in the given example after saving the machine code part and before typing in the BASIC stub in direct mode.