As for the first part of your question, yes, for sprites as well as characters or bitmap images the same principle holds: either you can be in single colour/hi-res mode (320x200, 1 bit of foreground colour info per logical pixel) or multi colour mode (160x200, 2 bits of colour info per logical pixel).
In practice, for PAL, a single colour pixel that is ...
In standard bitmap mode the C64 outputs 320 pixels in 40µs.
The visible portion of a line is ~52µs; in 60Hz regions ~240 lines are considered 'visible', but in PAL regions it's ~288 lines.
So if there were no borders, there'd be around 52/40*320 = 416 pixels across the visible portion of a line.
Given that each line is 4/3rds as wide as a hypothetical ...
The pixels are not exactly square, the actual aspect ratio depends on the TV system.
For PAL-B, the pixel aspect ratio is 0.937:1, the pixels are a bit higher than they are wide.
For NTSC, the ratio is 0.75:1. At this ratio it can be clearly seen that the cursor block is definitely higher than wide.
One, the fact mentioned by others, that you only need to be higher than the surface of a square to be able to create a body and teleport there. The bodies have nonzero height, so you can gain one body-height for free. However, looking at some videos, I'm not sure if that's enough to go to a higher level. Here, at 2:04, it appears that the body created by the ...
There were three types of elements: trees, cubes and Sentinels (1, 2, or 3 units of mass). So you could absorb e. g. 7 trees and build two cubes and an empty Sentinel on top of them. Then transfer your mind, absorb back the old Sentinel, and voila! - you are standing higher than before.
So the trees are the magic.
Stand at your desk. Look downward. Can you see your desk? If you were to teleport so that you were standing on top of it, would you be higher than you were before you teleported?
That said, the majority of height gains comes from the other gameplay element in The Sentinel — consuming and producing trees and boulders. Anything you consume gives you energy. ...
There are two essential elements to programming such smooth scrolling on the C64:
Use C64 hardware scrolling, which can move the screen in single pixel increments, but only for 8 pixels.
Use double buffering to scroll the back buffer by 8 pixels during the time that hardware scrolling is doing the front buffer.
Since hardware scrolling and screen swapping ...
How about intercepting CHROUT print routine and fixing the color value:
C000 LDA #$0B
C002 STA $0326
C005 LDA #$C0
C007 STA $0327
C00C LDA #$01 ; SET COLOR HERE
C00E STA $0286
C012 JMP $F1CA
I've been asked several times about discovered "interesting behavior" of the OCS chip set when the registers were updated at certain times in a certain order (at a certain rate, etc.), and whether that behavior was intentional or not.
Simple stuff like changing modes or palettes synchronized to the NTSC "beam" was intended.
But I am certain the design ...
If both the blitter's vertical and horizontal filling mode was enabled and launched on a stray pixel it created a simple fractal image known as the Sierpinski triangle. It can be seen in use in the 4K intro Heartcore by Delon.
Another famous trick was rewriting BPLCON1 (the copper scroll register) to emulate a zooming effect as seen in many Sanity demos ...
The "problem" with a screen text rendering routine that also sets the color of each character cell it outputs is performance. It requires two writes for each character, but only one is required if you want to keep whatever color(s) are already assigned.
If you are looking to improve the performance of the PRINT used in BASIC by foregoing unnecessary writes ...
Big box Amigas (A3000/A4000) with Zorro-III 32-bit bus can accommodate 256MB RAM expansion cards, which are still being manufactured today. Utilizing 4 Zorro-III slots, this allows memory expansion of 1GB, which is quite substantial for a 68030/40/60 based computer. I'm not sure how you'd use it all, excepting some bespoke application that you could write ...
Maybe you could peek the color at the specified address before you print it. Else, if color ram has different colors at each character location where you want to print, the next idea would be to poke the characters at screenmem (which does not affect colorram). I also think that you can define a function using DEF FN() that peeks and pokes characters (i.e. ...
And now here are some really non-trivial hacks played with amiga chipset:
7-bitplane ECS hack: https://groups.google.com/forum/#!topic/comp.sys.amiga.misc/HQBzx6E0K1Y (see the first message in the topic)
When you fill register $dff100 with value which has the number of bitplanes specified as 7 (lo-res) something strange is going on.
On screen you will ...
One approach would be to mirror the BASIC ROM into RAM where it can easily be modified, and then simply NOP the instructions that perform the color change.
I outline the technique used to mirror the ROMS into RAM in this post
Mapping the 64 seems to indicate the BASIC PRINT routing is located at $AAA0, and eventually calls the Kernal CHROUT. I would start ...
If one game would qualify, that would be Alien Breed: the game switches from PAL to NTSC rapidly to emulate a damaged CRT display (extract of longplay at this point). A PAL to NTSC switch should occur at the top of a frame, so doing that in the middle of a frame can be considered like exploiting a bug.
Now, whereas games didn't push the tricks too far, that ...
The Amiga OCS was not exploited in the same way as the C64's VIC-II simply because the OCS was designed from the beginning to support rapidly changing video output modes.
Unlike the C64, and most 8-bit machines, the Amiga's display coprocessor (the "Copper") existed to allow display mode updates to occur many times during the raster. For machines like the ...
this fixes the decimals in the sys to 5
10 SYS00000 (and as such the string now has a fixed length). wastes 1 byte but then again a space also wastes 1 byte and that's common enough in stubs.
guess you can add "IF BASICSTART+STUBSIZE >= 10 /100/1000/10000 decimal" changes to the added values to cover for all eventualities along with some extra .ASCIIZ ....
The highest capacity DRAM to ever be used for the Commodore 64 motherboard was 256Kbit. By the early 1990s, 1Mbit DRAM was commonplace, but used in a 256Kbx4 would require the C64 to have 256KB of main memory. It was almost certainly cheaper to continue to source the 256Kbit RAMs than to either upgrade the C64 to support 256KB of RAM near its end-of-life, or ...
ca65 was designed as a single-pass assembler. So this works:
addr = 4096
.byte $9e,.sprintf("%d", addr)
but this does not:
.byte $9e,.sprintf("%d", addr)
addr = 4096
--> Error: Constant expression expected
The expression can't simply be constant; it must be constant and has to be defined before the sprintf ...
There is a .sprintf function in ca65, but it appears to only work with constant values.
Excatly. That's why there's the first error (Error: Constant expression expected) occurs. Sprintf is evaluated right when the source is parsed. So it behaves much like a macro in C.
The second error (Syntax error) is due the parentheses around sprintf.
Try something ...