(hide navigation)
  • Swedish content
Fund my projects
Log in
Latest comments
RSS feed

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.

Apr 2014

Tracking down the ^Z problem in vim

Sun 6-Apr-2014 19:43
Why ^Z and not :q or even :wq ?


Sun 6-Apr-2014 22:01
I am most impressed with the speed and clear font of this interpreter. It's even faster than the official Infocom games on my Atari ST!

I would like to change the default colors to green on black, as black on white is a little hard on my eyes.

I have tried changing the values for 'black' and 'white' in the source code, and recompiling it, but that doesn't seem to do anything. (It compiles fine, but the colors don't change.)

Unfortunately, I don't understand assembler at the best of times, and am getting a bit lost!

The TTY demystified

Thu 10-Apr-2014 12:05
> Writing to a TTY which is stopped due to flow control, ...... will block your process

I can't understand? The process will not blocked when TTY is stopped by flow control(ctrl+S), the foreground process will continue running. The only difference is I can't see the display until I type ctrl+Q again.

Thanks for you article

Tracking down the ^Z problem in vim

Sun 13-Apr-2014 16:13
Why ^Z and not :q or even :wq ?

^Z will suspend the process and allow it to be resumed later with "fg" (in Bash and similar shells).

This can matter if it takes a long time to start up Vim again (slow system, slow disk), or if you have a lot of windows or tabs you don't want to have to reconfigure.

Poems for bugs

Fri 18-Apr-2014 12:02
Have fun at Revision 2014! I'm staying a sofascener for now. --jn

GCR decoding on the fly

Fri 25-Apr-2014 16:04
Great work. I think if you made receive loops timed for each of the 4 bitrates, you could read 5 bytes before resynching. You could probably even do it with 2 loops (each covering 2 bitrates).
Take a look at the code from Epyx Winter Games if you haven't already. Other than the directory track, the disk doesn't use GCR. And I'm pretty sure (memory isn't perfect after almost 30yrs) it transferred 253 or 254 bytes at a time, pushing them on the stack on the c64 side in order to save a cycle vs sta.