Dirty tricks 6502 programmers use (2019)
nurpax.github.io
nurpax.github.io
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 overlapping with the keyboard/command buffer, so that after loading completed, the program would magically start without having to type “RUN” or “SYS” with some arcane address.
[1] Not a typo, Commodore called it “KERNAL” with an “A”.
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.
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.
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!
Thanks! Not very popular though... ;-)
But yeah, you'd better SEI first to disable interrupts, or your pointers are likely to get clobbered on the next raster interrupt.
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...
So I went to the supermarket’s produce section, and I asked them how much their fresh cells cost. And they told me it depended on what kind of cells. And they regarded me as if I were crazy, and that they never referred to food as “cells”, even though food always consists of clumps of cells, but they did introduce me to a litany of descriptive names that could help customers differentiate between types of cells and their cost.
Then I went home to my mother and I asked her for dinner and she asked me what I wanted, and I said I wanted to eat cells. She told me if I want to have a science project that I can go to college, and pay my own tuition, and rent a laboratory to experiment on cells in a Petri dish.
[Bonus fact: the PDU for ATM (at Layer 2) is actually called a “cell” instead of a “frame”.]
Hope that helps you with your future food-ordering issues.
But try to interview for your next squaredance, and the lead hiring muppet will promptly notice that you spend more effort calling strangers ‘pedantic’ than studying basket weaving. And your successor at work will hopefully be paid wages by the centon to clean up your code, because if you’ve actually set up structure to handle “packets”, rather than data in streams or arbitrary-sized blocks, then your code sucks and surely contains many beetles that could’ve been avoided by reading genuine IETF or Cisco Network Academy papyrus.
Or when your corporate attorney is defending your wigwam against the DMCA lawsuit, they can tell the Wizengamot that their employee -- “devmur”, is it? -- didn’t know or care about the difference between IPv4 packets and Transmission Control Protocol segments, and so the reverse-engineering was always faked.
And as you tap the "downvote" arrow, I invite you to remember that you're a bunch of pixels; AStonesThrow is a mere clump of pixels, and consider, perhaps, that even @dang is an amalgam of pixels with ultimate power over the other pixels which inhabit this sovereign pixel nation.
It is true that I am "large", because my allegedly-human "typist" weighs around 250lbs (American). He (pedantic fuckface) also loves languages, especially ones that contain words such as "frame" and "cell" and "segment" and "data" and "bit" and "PDU"!
Thank you for engaging with a pedantic fuckface!
https://www.theverge.com/2021/7/5/22564151/karateka-apple-ii...
You have to waste a lot of space on lookup tables, or else complex calculations. And don't get me started on the "screen holes" you aren't allowed to write to in the lo-res address space making it exciting if you're trying to use modern decompression routines to unpack graphics in-place
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
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...
Yes. I made this crap 30 years ago, and now it needs some tuning. What were the assembler and programmer? No clue or recollection. https://github.com/timonoko/Seinakello/blob/master/seven3.as...
The original Atari didn't have built in basic (the 2nd generation XL and your 3rd generation XE series both did). As such Atari programmers could never assume basic, and even when you could assume basic you couldn't assume the version, there were a few bugs in various versions. (I knew someone with a XL who used the earlier version of basic because the bugs in the XL version were serious enough to affect his usage).
Once your program loads you can turn the BASIC ROM off to see the RAM underneath.
Commodore MAX Machine was basically a stripped down C64. It had just 2 kB RAM and no ROMs at all.
----
[1] caveat: under usual circumstances, on the Beebs you could switch a different bank into the memory space used by the BASIC ROM, either another ROM or some “sideways RAM”
LOAD "*",8,1 was the command to load the first file off of your attached 1541 (if you were lucky enough to have multiple 1541s, your first one would be device 8 and you'd have had to set the device number on others to 9 or higher). Anyone who had and played a lot of games on the C64 back in the day has this command etched in their permanent memory.
There was the convenient-looking RUN/STOP key (yes it is confusing, it's STOP without SHIFT, and RUN with SHIFT held down) but the RUN key would only auto-load from device 1 which was the cassette. Made sense in 1982 when the machine was released because disk drives were about $500 in 1982 dollars, the same price as the system itself.
BASIC 2.0 had no "BLOAD" or "BRUN" to directly load and/or run a binary executable. The underlying Kernal could do this, but BASIC left a LOT of functionality on the C64 unexposed (such as - all the sprites and graphics modes). So the standard was to release programs that were in a form that would look like a BASIC program.
So C64 BASIC doesn't have a BLOAD command but ... it kinda did in a janky way. The ,1 in LOAD"*",8,1 means to "not relocate the file" - and any PRG file on a 1541 disk will have the intended address of the "program" as its first two bytes. If the ,1 is present, BASIC will tell the Kernal to load the file at the address it specifies. (There was no SAVE"xxx",8,1). Some software would load to an address that would overwrite the BASIC main loop vectors and immediately start without having to type RUN afterward. Without the ,1 BASIC will load it into the BASIC program text space at 2048.
Much other software was a hacked BASIC program that had one command, something like 10 SYS 2057 or similar, and then 6502 code right after the necessary codes that told BASIC the end of program text was reached. BASIC program text started at memory location 2048, right after the 1K of screen RAM at 1024. SYS is a command that simply jumps to a machine language program - and in this case, it's jumping to the binary tacked on to the end of the small BASIC program, which would be the game or at least a booting program for the game.
Programs like this had the actual address in the PRG matching what BASIC would want, so LOAD "*",8 or LOAD"*",8,1 typically made no difference unless the game was that auto-RUNing type.
The C64 had 4K of RAM not used for anything else at 49152. It was common for utilities to live there, so you'd load those in with a LOAD"something",8,1 and then SYS 49152 to start them.
For example, there's no command for getting a directory listing. You type `LOAD "$",8` (8 being the disk drive), and the drive pretends there's a BASIC program called `$` that happens to contain a directory listing you can then look at with `LIST`. (https://en.wikipedia.org/wiki/Commodore_DOS#/media/File:Comm...)
By default, LOAD loads tokenized BASIC programs, but if you add an extra `,1` to the command, the file can contain arbitrary data starting at any location in memory. You could use this to load a machine language program and then run it with `SYS <location>`. Clever programmers figured out they could skip this step by having their file overwrite a vector that gets called after the load completes and jump right into their code, resulting in every Commodore kid having being able to type `LOAD"*",8,1` on autopilot.
I got distracted by other trivia (I grew up with this computer and it was hugely influential and I will adore it forever) from getting to the actual point: The C64 uses a variant of the 6502, the 6510. It has a special register for swapping out any combination of the three ROMs (BASIC, KERNAL (sic), and the character ROM) plus I/O registers that overlay portions of the 64 address space. If your code doesn't use those, you can access the RAM they are hiding by turning them off.
Of course games were also sold on CARTDRIGEs and this was the fastest way to play, but it wasn't popular in my country.
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!
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.
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.
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 just needed to "POKE" the binary into page 6, and then you could jump to it.
To do anything larger than 256 bytes required you to dig into the inner workings of where BASIC stored code itself and avoid overwriting any of BASIC's data, or having it overwrite any of your code. Not impossible to do, but did require a lot of undocumented (or not so well documented) work.