Denial

So we can meet there :) For the record, tokra had his VIC-20 set up and running on a table right next to the central corridor. ... BTW, tokra and I had a nice meetup with two graphicians from Poland (skrzyp and Erick Elis of INBA Systems) who were amazed seeing skrzyp's entry to the Oldskool Graphi...

Did converting this game to load from disk force the use of a RAM expander? Those are just bad "cracks" - not that the game actually had a copy protection of any noteworthiness. However, bringing all the data into place from disk instead of tape might require some extra memory, because ta...

Thank you!

wrote:You should seriously consider giving it again, or even doing a YouTube version for us!

Edit: The video is up here: https://www.youtube.com/watch?v=LiPrL9788wU. Enjoy!

Greetings,

Michael

To those interested,

I will give a seminar lecture on the topic of Machine Language Monitors on Revision 2024.

The seminar is scheduled on Friday, Mar. 29th, 6 P.M. CET (1 P.M. EST, 10 A.M. PST).

Greetings,

Michael

In this thread here, another recent thread about " Recommendations for VIC-20 assembly tutorial[s], tools " already had been mentioned. In that other thread you will find the link to my VICMON primer . That one specifically aims to make the bridge between a high level language (here, BASIC...

Do the tables get generated each time the routine is called or only once on initialisation? I suppose you mean the tables that are written in lines 20..27 of the test rig: these of course need only be written once, at program start. The main loop of the test rig just sets random co-ordinates for th...

pixel wrote:Now for chasing zombies… how did printing decimals work again?

See the thread "Printing (unsigned) 16-bit numbers in Assembly, how?".

I'm curious: what if you had y2>y1, so lines were always drawn in one direction vertically as well? You can't have both. Given x2>x1 and y2>y1, a line on screen looks like a backslash, "\", assuming a left-handed co-ordinate system. You can't enforce y2>y1 though when the endpoints alread...

Warning, longer post. Before I posted my own version of the "20000 pixels/second" line routine on the previous page, I also had a PM exchange with Merytsetesh about MrSterlingBS's original implementation: I'll take a look into this the next days whether I can derive a version of the routi...

That is actually the job of CLRCHN . CLALL in addition only rudely purges the table of open files (by setting the number of open files to 0) and there is only one single instance in ROM where a JSR $FFE7 is used - by the BASIC interpreter to ensure there are no (pre-)allocated logical file numbers a...

You need to differentiate clearly between PETSCII codes (i.e. what is used with CHROUT and CHRIN), screen codes (what is stored in the text screen RAM) and glyphs (the actual definition of a character matrix in the character ROM or as user defined character in RAM). What algorithm is used to pull ou...

[...] asking for the screen size returns hard coded values. It would have been nice if that was dynamic, but sadly too late. The KERNAL call JSR $FFED (SCREEN) is beyond uselessness. It assumes a level of abstraction (regarding the screen size) that at that time neither was expected nor required fr...

MrSterlingBS wrote:[...]

PM sent

Here's my take on this subject: Before any questions come up in this regard: MINIGRAFIK already contains a line routine, which is not as fast as the routine below, however it is much more compact (just about 100 bytes extra beyond the pixel set function otherwise already provided within the MG code)...

The KERNAL is accessed through a jump table in RAM. You can change those jump points and switch out any KERNAL subroutine you want without having to replace ROMs. That is the same case with the C64, but it did not give people a reason not to produce modified KERNAL ROMs. Edit/Addition : That being ...