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

21–30 of 68 posts

Re: Dirty tricks 6502 programmers use (2019)

#21

Post by p0w3n3d »

masto wrote: post #18
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?

The C64 starts up straight into BASIC from ROM. Unlike some other contemporary computers, it doesn't attempt to boot from any external devices (except the cartridge port). There isn't really a DOS in the usual sense. Apart from simple support for loading and saving programs, and a very basic channel I/O facility, everything else is handled by the firmware in the disk drive, which has its own 6502 and operating system…

On my ATARI there was no DOS too. When you start the 65XE you can hold (iirc) START to start loading an application from the cassette recorder, but it was recommended to hold both (again iirc) START and OPTION to bypass BASIC, because BASIC interpreter being held in the memory, somehow interfered with bigger games (I think this was due to memory, but I'd like to learn from someone who know). I myself got into this trouble sometimes. Also you could have a CARTDRIGE with DOS-like Turbo management which allowed to scan cassette for given filename with binary application, but no one used this because it would take crazy long. I never had chance to use floppy disk, but I think it was behaving in a similar way (you had to have a floppy with DOS and hold START when powering the computer to load it), but at that time the FDD drives for atari were horryfyingly expensive (they had the same CPU 6502, and even there were some demoes which used this CPU as a coprocessor), so I stayed with a cassete reader with TURBO.

Of course games were also sold on CARTDRIGEs and this was the fastest way to play, but it wasn't popular in my country.

Re: Dirty tricks 6502 programmers use (2019)

#22

Post by flohofwoe »

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…

The best 8-bitter video memory layout (for pixel data) I have seen is in the little known KC85/4:

The display is 320x256 pixels, organized into 40x256 bytes for pixels (8 pixels per byte) and another 40x256 bytes for Speccy-like color attribute bytes (the color blocks are just 8x1 instead of 8x8 pixels), the start address for video memory is 0x8000 with the pixels and colors in different memory banks.

Now the twist: the video memory layout is vertical, e.g. writing consecutive bytes in video memory fills vertical pixel columns.

This layout is perfect for the Z80 with its 16-bit register pairs. To 'compute' a video memory location:

    LD H, 0x80 + column    ; column = 0..39
    LD L, row              ; row = 0..255
...and now you have the address of a pixel- or color-byte in HL.

To blit an 8x8 character just load the start of the font pixels into DE and do 8x unrolled LDI.

Unfortunately the KC85/4 had a slow CPU clock (at 1.77 MHz only half as fast as a Speccy), but it's good enough for stuff like this:

https://floooh.github.io/kcide-sample/kc854.html?file=demo.k...

Re: Dirty tricks 6502 programmers use (2019)

#25

Post by djmips »

flohofwoe wrote: post #22
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…

The best 8-bitter video memory layout (for pixel data) I have seen is in the little known KC85/4: The display is 320x256 pixels, organized into 40x256 bytes for pixels (8 pixels per byte) and another 40x256 bytes for Speccy-like color attribute bytes (the color blocks are just 8x1 instead of 8x8 pixels), the start address for video memory is 0x8000 with the pixels and colors in different memory banks. Now the twist:…

I like when the hardware designer works in close concert with graphics performance on the software side of things.

Re: Dirty tricks 6502 programmers use (2019)

#27

Post by miramba »

p0w3n3d wrote: post #21
masto wrote: post #18

Earlier quoted context omitted.

The C64 starts up straight into BASIC from ROM. Unlike some other contemporary computers, it doesn't attempt to boot from any external devices (except the cartridge port). There isn't really a DOS in the usual sense. Apart from simple support for loading and saving programs, and a very basic channel I/O facility, everything else is handled by the firmware in the disk drive, which has its own 6502 and operating system…

On my ATARI there was no DOS too. When you start the 65XE you can hold (iirc) START to start loading an application from the cassette recorder, but it was recommended to hold both (again iirc) START and OPTION to bypass BASIC, because BASIC interpreter being held in the memory, somehow interfered with bigger games (I think this was due to memory, but I'd like to learn from someone who know). I myself got into this tr…

Yes, Option would disable Basic on boot. The first Ataris (400 and 800) came with a basic module that you had to put in and then start the computer to use Basic - or likewise Assembler. The module would then use certain parts of the precious 64 KB Ram - actually, much less because the OS in ROM would write itself into RAM on startup and take about 20KB away. So a program or game had about 40 KB space to use. Basic would take some more away. Which wasn‘t a problem on the 800, you would either plug the module in and use Basic but you wouldn‘t if you wanted to load a game. But with the XL, you needed a way to disable the automatic Basic load at boot time, or many games could not use all of the memory they needed. Hence, the Option-option at startup.

At least I remember it this way, but I only had an XL, not the older ones, and now I remember that the 800 had only 48KB of RAM, so it was probably more complicated than that!

Re: Dirty tricks 6502 programmers use (2019)

#28

Post by pwg »

p0w3n3d wrote: post #21
masto wrote: post #18

Earlier quoted context omitted.

The C64 starts up straight into BASIC from ROM. Unlike some other contemporary computers, it doesn't attempt to boot from any external devices (except the cartridge port). There isn't really a DOS in the usual sense. Apart from simple support for loading and saving programs, and a very basic channel I/O facility, everything else is handled by the firmware in the disk drive, which has its own 6502 and operating system…

On my ATARI there was no DOS too. When you start the 65XE you can hold (iirc) START to start loading an application from the cassette recorder, but it was recommended to hold both (again iirc) START and OPTION to bypass BASIC, because BASIC interpreter being held in the memory, somehow interfered with bigger games (I think this was due to memory, but I'd like to learn from someone who know). I myself got into this tr…

The original Atari 400/800 included BASIC on a ROM cartridge.

To use BASIC, you plugged the BASIC cartridge into the system and powered up.

To boot something else (games...., from either cassette or disk) you first removed the cartridge, then powered up.

With the XE series, BASIC was built in to the console, so the "magic keys" were needed to tell the hardware to virtually "unplug" the BASIC ROM before it tried booting from any connected devices.

Re: Dirty tricks 6502 programmers use (2019)

#29

Post by miramba »

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.

Re: Dirty tricks 6502 programmers use (2019)

#30

Post by pwg »

miramba wrote: post #27
p0w3n3d wrote: post #21

Earlier quoted context omitted.

On my ATARI there was no DOS too. When you start the 65XE you can hold (iirc) START to start loading an application from the cassette recorder, but it was recommended to hold both (again iirc) START and OPTION to bypass BASIC, because BASIC interpreter being held in the memory, somehow interfered with bigger games (I think this was due to memory, but I'd like to learn from someone who know). I myself got into this tr…

Yes, Option would disable Basic on boot. The first Ataris (400 and 800) came with a basic module that you had to put in and then start the computer to use Basic - or likewise Assembler. The module would then use certain parts of the precious 64 KB Ram - actually, much less because the OS in ROM would write itself into RAM on startup and take about 20KB away. So a program or game had about 40 KB space to use. Basic wo…

> much less because the OS in ROM would write itself into RAM on startup and take about 20KB away.

RAM shadowing of the ROM did not exist in the Atari's (at least not in the original 400/800 models). The ROM's simply were physically connected to actually "be" the top 16KB of the 6502's 64k max address space. The CPU executed the ROM code by directly reading the code from the ROM chips.

Which is also the reason the original 400/800 models were limited to 48k max RAM. 16k of the address space was already used by the ROMs.

Post reply on HN