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

51–60 of 68 posts

Re: Dirty tricks 6502 programmers use (2019)

#51

Post by anyfoo »

pacificmint wrote: post #46
anyfoo wrote: post #39

Earlier quoted context omitted.

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.

Yep! For those reasons, it was more or less the "default" target for assembly programs without special requirements. So much so that even as a child I knew "SYS49152" ($C000 in decimal) by heart.

Re: Dirty tricks 6502 programmers use (2019)

#52

Post by delusional »

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.

From that thread:

> The semi translucent spectres causing VGA reads were very bad on that machine, causing I absolutely love that. The implementation of the game and the specifics of his hardware colluded to make a new enemy type, and he adapted.

What a cool story.

Re: Dirty tricks 6502 programmers use (2019)

#53

Post by AStonesThrow »

devmor wrote: post #4
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…

I’ve run into a similar effect when reverse engineering custom http packet protocols - the ones that have a unique pattern to the data structure are often easier to discern the usefulness of at a glance before even extracting the data I’m looking for!

What are “http packets”? [Spoiler: there is no such thing]

http is an application-layer protocol. The PDU for http is “data”. http is stream-based due to being built on TCP, where the PDU is a “segment”.

https://en.wikipedia.org/wiki/OSI_model#Layer_7:_Application...

Re: Dirty tricks 6502 programmers use (2019)

#54

Post by DidYaWipe »

pwg wrote: post #20
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?

On the Atari's you could also run 6502 binaries from inside Atari BASIC. The Atari ROM OS explicitly reserved page 6 of the memory map for "user use" and Atari Basic followed suit. There were (IIRC) also a tiny number of page 0 bytes reserved for 'user use' as well. So, as long as your entire binary fit into 256 bytes, you could run it from inside BASIC. In fact, you could even store it as a BASIC program, the BASIC…

You might have been able to store the opcodes in strings, letting BASIC put them in memory somewhere and then getting the address.

A cool trick to move your player/missile graphics vertically in BASIC was to store the sprites in strings, point the sprite's starting memory to the address of the string, and then use string-copying routines in BASIC to move the sprite up & down (since they only had a horizontal-position register; vertically they were as tall as the screen, so you had to blit them to get vertical movement).

Re: Dirty tricks 6502 programmers use (2019)

#55

Post by djmips »

chillingeffect wrote: post #47

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…

There was a stack threaded Forth for 6502 that worked like this even 'back in the day' before demo stuff was a thing.

Re: Dirty tricks 6502 programmers use (2019)

#56

Post by chillingeffect »

djmips wrote: post #55
chillingeffect wrote: post #47

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…

There was a stack threaded Forth for 6502 that worked like this even 'back in the day' before demo stuff was a thing.

ahh that's probably where they got the idea :)

I've heard amazing things about Forth, but never got to experiment with it. I've seen some Forth carts for C64. As soon as I get my CIA chip squared away, I should experiment :)

Dude btw you have some awesome submissions!

Re: Dirty tricks 6502 programmers use (2019)

#57

Post by aaronbaugher »

chillingeffect wrote: post #47

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…

I haven't seen it either, but it should be doable as you describe. A TSX will transfer the stack pointer to the X register, so that would tell you where to start inserting the pointers you want to "jump to" on the next RTS. There's nothing to stop you writing directly into the stack page, other than sanity.

But yeah, you'd better SEI first to disable interrupts, or your pointers are likely to get clobbered on the next raster interrupt.

Re: Dirty tricks 6502 programmers use (2019)

#58

Post by ddingus »

DidYaWipe wrote: post #54
pwg wrote: post #20

Earlier quoted context omitted.

On the Atari's you could also run 6502 binaries from inside Atari BASIC. The Atari ROM OS explicitly reserved page 6 of the memory map for "user use" and Atari Basic followed suit. There were (IIRC) also a tiny number of page 0 bytes reserved for 'user use' as well. So, as long as your entire binary fit into 256 bytes, you could run it from inside BASIC. In fact, you could even store it as a BASIC program, the BASIC…

You might have been able to store the opcodes in strings, letting BASIC put them in memory somewhere and then getting the address. A cool trick to move your player/missile graphics vertically in BASIC was to store the sprites in strings, point the sprite's starting memory to the address of the string, and then use string-copying routines in BASIC to move the sprite up & down (since they only had a horizontal-position…

Yes, I learned that trick out-of the blue book, de re Atari I believe. Hard to remember.

I also used that trick to scroll one of the lower resolution graphics screns for a brick out type game that would inch whatever was left toward the player.

Re: Dirty tricks 6502 programmers use (2019)

#59

Post by devmor »

AStonesThrow wrote: post #53
devmor wrote: post #4

Earlier quoted context omitted.

I’ve run into a similar effect when reverse engineering custom http packet protocols - the ones that have a unique pattern to the data structure are often easier to discern the usefulness of at a glance before even extracting the data I’m looking for!

What are “http packets”? [Spoiler: there is no such thing] http is an application-layer protocol. The PDU for http is “data”. http is stream-based due to being built on TCP, where the PDU is a “segment”. https://en.wikipedia.org/wiki/OSI_model#Layer_7:_Application...

An HTTP packet is a packet sent over TCP for an HTTP request. IoT vendors like to re-use HTTP and build custom protocols on top of it. Pedantry isn't useful or helpful here.

Re: Dirty tricks 6502 programmers use (2019)

#60

Post by ako »

pacificmint wrote: post #46
anyfoo wrote: post #39

Earlier quoted context omitted.

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.

Basic interpreter used $a000 to $c000 if I remember correctly, and screen buffer characters was at $400. If you didn’t need to display anything you could use it for something else.
Post reply on HN