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

1–10 of 68 posts

Re: Dirty tricks 6502 programmers use (2019)

#3

Post by dhosek »

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 every three (non-consecutive) rows made calculating row starts much simpler.

Re: Dirty tricks 6502 programmers use (2019)

#4

Post by devmor »

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!

Re: Dirty tricks 6502 programmers use (2019)

#5

Post by codezero »

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!

Have you written about this anywhere? Sounds like a fun blog post to read :)

Re: Dirty tricks 6502 programmers use (2019)

#6

Post by univacky »

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…

When Jordan Mechner wrote Karateka for the Apple ][, he used an array of pointers to rows. A team member realized that by inverting the order of the array, all graphics would appear upside down. Broderbund agreed to ship that "upside down" version on the backside of the single-sided floppy, so that if you booted it upside down it played upside down.

https://www.theverge.com/2021/7/5/22564151/karateka-apple-ii...

https://archive.org/details/wozaday_Karateka_Side_B

Re: Dirty tricks 6502 programmers use (2019)

#7

Post by p0w3n3d »

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?
Post reply on HN