Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dirty tricks 6502 programmers use (2019)

nurpax.github.io

Post reply on HN
Print view View original

41–50 of 68 posts

Re: Dirty tricks 6502 programmers use (2019)

#41

Post by anyfoo »

dhosek wrote: post #3

I remember the annoyance a lot of people had with the non-sequential layout of text/graphics memory on the Apple ][ (thanks to Woz’s clever hacks to reduce chip count), but when writing assembly code to access screen locations, it turned out that it was actually easier to deal with the somewhat weird arrangement of bytes than it would have if everything were sequentially arranged in memory. Those little 8-byte gaps e…

Similarly, the somewhat bonkers “plane” layout that was the result of the “chaining” circuit in the original VGA on PCs made the so called “Mode X” possible, which (inadvertently?) enabled fast animation, critical for games like DOOM.

Re: Dirty tricks 6502 programmers use (2019)

#42

Post by anyfoo »

miramba wrote: post #29

Looking at the page, I barely remember those assembler commands. LDX, STA, INX..I’m glad that this is obsolete now. But I wonder how common the knowledge is these days that ultimately, every programming language compiles down to this? Well the equivalent of this on a modern processor, but still.

Why are you glad that it is obsolete? 6502 assembly is severely limited, having only one general purpose register, i.e. the accumulator, and two index registers (but some fun addressing modes), but apart from some quirks, it’s relatively straightforward for a CPU of its size?

Re: Dirty tricks 6502 programmers use (2019)

#43

Post by turtledragonfly »

miramba wrote: post #29

Looking at the page, I barely remember those assembler commands. LDX, STA, INX..I’m glad that this is obsolete now. But I wonder how common the knowledge is these days that ultimately, every programming language compiles down to this? Well the equivalent of this on a modern processor, but still.

> But I wonder how common the knowledge is these days ...

In one sense, it is less common, as you imply (though perhaps it's more that the number of high-level programmers have ballooned, rather than that the low-level ones have shrunk).

In another sense, it's more accessible than ever, with tools like godbolt[1][2], VMs, cool profilers that show you a heatmap overlaid on assembly instructions, etc.

And embedded development, where those details matter more, is still going strong, with IoT devices and so forth.

[1] part of a presentation on it, if you're not already familiar: https://www.youtube.com/watch?v=kIoZDUd5DKw&t=1191s [2] the site itself: https://godbolt.org/

Re: Dirty tricks 6502 programmers use (2019)

#45

Post by dhosek »

lscharen wrote: post #36
dhosek wrote: post #35

Earlier quoted context omitted.

Hmm, I don’t remember there being anything special about those little 8-byte holes in the lo-res/text memory.

There are 8 screen hole bytes in the bottom 8 text rows (64 bytes total) and 8 expansions slots, so the screen hole byte at offset "N" was often used to store up to 8 bytes of data[1] (one byte in each of the rows' screen hole area) by the expansion card's firmware in Slot "N". Overwriting those bytes could result in system crashes and hardware hangs. [1] https://retrocomputing.stackexchange.com/a/2541/3653

Ah, I remember using the memory holes in the HIRES graphics memory for scratch-pad usage, but had forgotten about this part. I loved the Apple ][ since it (up to the //e) was capable of being fully understood by a single human being. Few if any computers since then have held that distinction

Re: Dirty tricks 6502 programmers use (2019)

#46

Post by pacificmint »

anyfoo wrote: post #39
pnw wrote: post #32

My VIC-20 coding trick as a 14 year old was to use the 828 byte cassette buffer for storage in my games because it took me forever to save up for the 6.5k RAM expansion.

When programming assembly, it was common to just indiscriminately use all RAM, not matter what the kernal[1]/basic used it for. When programming basic, it was common to use memory regions that were meant for something else for yourself if you don’t need it, like you did, knowing that you won’t use the cassette routines. On the C64, there were some common “autorun” tricks that loaded the program into a buffer overlapp…

There was also that 4k block of memory at $C000. It was in between the ROM blocks, and by default it was totally unused.

Basic couldn't utilize it, but in assembly it was a great area of extra memory, and you could use it without even switching the ROMs off.

Re: Dirty tricks 6502 programmers use (2019)

#47

Post by chillingeffect »

One of the neatest things I've heard demo scene people do on the 6510/6502 is a "stack machine." I don't know exactly, but fwiw I understand, it works like this:

it's using the stack page, 256 bytes from 0x100 - 0x1ff. It generally stores two-byte pointers to code. When each routine finishes, it calls RTS and the CPU automatically pulls the next 16-bit addr from the stack and jumps to it. You never call JMP, JSR, etc, never pushing your address onto the stack! And I think you can also do tricky things like throw in some code executing in that space, too. And I think it can loop around, too, so you have a basic set up of 128 slots for routines that can switch between them very quickly. You can also write to the SP (stack pointer) to jump around in the slots.

p.s. pray you don't get any interrupts while this is going on unless you absolutely know what you're doing :)

Apologies if I haven't got this right. I've never seen it, only heard about it.

Re: Dirty tricks 6502 programmers use (2019)

#48

Post by TacticalCoder »

dspillett wrote: post #12
p0w3n3d wrote: post #7

Quite surprising for me as a long time Atari 65XE user is that those PRG were starting with a basic command. On Atari all binary programs were loaded without BASIC in memory. If you forgot to disable basic, there was a chance the program wouldn't run or would hang. I guess this must have been due to different memory layout?

IIRC the C64, like the BBC range of 6502-based Micros, had their BASIC in ROM and in fact booted to it in REPL mode by default. As such it was always in memory as the ROM would always be there¹. There were certain bits of the address space that were not safe to use if the user would drop back into BASIC as the ROM used those for its stack & heap and other scratch space, but otherwise you could ignore BASIC's existenc…

[dead]

Re: Dirty tricks 6502 programmers use (2019)

#49

Post by smcin »

anyfoo wrote: post #41
dhosek wrote: post #3

I remember the annoyance a lot of people had with the non-sequential layout of text/graphics memory on the Apple ][ (thanks to Woz’s clever hacks to reduce chip count), but when writing assembly code to access screen locations, it turned out that it was actually easier to deal with the somewhat weird arrangement of bytes than it would have if everything were sequentially arranged in memory. Those little 8-byte gaps e…

Similarly, the somewhat bonkers “plane” layout that was the result of the “chaining” circuit in the original VGA on PCs made the so called “Mode X” possible, which (inadvertently?) enabled fast animation, critical for games like DOOM.

“Mode X” was discussed in comments on https://news.ycombinator.com/item?id=29088881 , don't think it's ever been the subject of a post on HN but it should.

Re: Dirty tricks 6502 programmers use (2019)

#50

Post by anyfoo »

smcin wrote: post #49
anyfoo wrote: post #41

Earlier quoted context omitted.

Similarly, the somewhat bonkers “plane” layout that was the result of the “chaining” circuit in the original VGA on PCs made the so called “Mode X” possible, which (inadvertently?) enabled fast animation, critical for games like DOOM.

“Mode X” was discussed in comments on https://news.ycombinator.com/item?id=29088881 , don't think it's ever been the subject of a post on HN but it should.

Some interesting stuff in there, I didn't know that DOOM used a variation of it called "Mode Y". (Even though I must have read about it at some point...)
Post reply on HN