linusakesson.net

Forum comments in chronological order

Disclaimer: I am not responsible for what people (other than myself) write in the forums. Please report any abuse, such as insults, slander, spam and illegal material, and I will take appropriate actions. Don't feed the trolls.

Jag tar inget ansvar för det som skrivs i forumet, förutom mina egna inlägg. Vänligen rapportera alla inlägg som bryter mot reglerna, så ska jag se vad jag kan göra. Som regelbrott räknas till exempel förolämpningar, förtal, spam och olagligt material. Mata inte trålarna.

Dec 2017

Massively Interleaved Sprite Crunch

Anonymous
Fri 1-Dec-2017 04:03
If your crunched sprite starts at offset 0x35 what do you do to get there to begin with? Do you start at 0 with the FG color set to black or in the top border and do some dummy crunch to traverse the graph to the right starting point?

Was wondering that myself. I guess that's what he means. Im unsure of the benefit of this though, as opposed to simply changing the sprite definition pointer. The sprite hasnt ended, and loops back... so I guess you can change the def and effectively have the sprite "start again". It's still the same sprite though, as opposed to the 17 pixel sprites that are the minimum.

On another topic, it seems the demo can behave a bit weird with multiple disk drives present on the serial bus (tried with a real 1541 as drive 8 and an Ultimate-II as drive 9)... could it be that you implement some custom serial protocol which the other drive might respond to or something?

Nearly all modern demo loaders have the same issue. They uses the various lines in weird ways, which means the ATTN line (from memory) is getting smashed and confusing other attached drives.

Could possibly be worth enumerating the attached drives at the start and putting all drives except #8 in a hard loop of some kind, but the easier solution is to just turn off all drives except #8 when watching a demo :)

StY1z000r

GCR decoding on the fly

Anonymous
Mon 11-Dec-2017 08:33
Also from my side my best congratulations!!! As a teenager I analysed all the fast loaders that were accessible to me at that time and I understood the tricks they were using on the GCR decoding and the serial transmission stuff. I even wrote a fast loader myself as a hobby (on paper, it never made it into a production state). So I want to say that I highly appreciate all the tricks you came up with - great, great stuff!!!

The TTY demystified

Anonymous
Mon 11-Dec-2017 19:21
@OP, Btw do you have any "to the metal" UNIX/linux books to recommend that has information regarding such stuff?

GCR decoding on the fly

Anonymous
Wed 13-Dec-2017 07:25
Just wanted to add to my comment from 11-Dec-2017 some things I forgot to mention. One of the fasted data transmission routines I analyzed in my teenage years was the one from Heureka Sprint. Heureka Sprint was a program 'listing of the month' in the German magazine '64er'. Is was especially remarkable since it used a different GCR encoding, which was much faster but less efficient; as far as I remember it could only store 228 bytes per block (maybe it used 6 instead of 5 bits per nybble?). You had to use the program provided to store your applications in the different format on your disk. But boy, it really loaded extremely fast!!! Another trick I think I came across that I would like to mention was to load the sectors out of order, and just store them out of order in the correct memory place in the C64, just as they came across the reading head of the drive, to avoid having to reformat the sectors in a particular order. Might be interesting to mention...

The TTY demystified

Anonymous
Wed 20-Dec-2017 22:15
Amazing article!

A Mind Is Born

Anonymous
Tue 26-Dec-2017 02:17
This is so awesome! Big respect Linus and thanks for the great explanation. I copied it on a physical disk, turned off the lights and started it on a 26" TV for full experience ;)
-stefan