IEC serial output bits

[Mike]

We had a discussion about this today and decided to release it publicly some time after the exclusive access launch for members. I'll tell you what it is when it has been announced.

O.K.

[Vic20-Ian]

Einverstanden.

I am on my own side regarding this matter.

Yes, on reflection you really are.

I politely suggested he reconsider.

[bjonte]

Today, the Swedish Commodore Club released its Swedish disk magazine, running on VIC20 (and some other platforms). This was what I was working on. Later on it will be publicly released, but only an interesting read if you can understand Swedish.

[doug_in_nc]

Sounds interesting. I had a quick look at your website www.commodore.se and I’m guessing if you aren’t in Sweden you can’t join as it would be difficult to pay the membership (I have never heard of Swish, and I don’t have a Swedish bank account), so releasing it later on for those of us outside Sweden would be great.

[bjonte]

Yesterday this was released to the public. Not that useful if you aren't speaking Swedish though.

https://csdb.dk/release/?id=226955

[Mike]

It's always interesting for me to see other people's approaches to bitmap graphics on the VIC-20.

Here, the "text screen" assumes a rather unlucky position at $1E00, which blocks the range $1E00..$1EFF for the bitmap. The character layout provides a 176x160 bitmap in the upper part (spanning $1000..$1DBF) and a 176x16 "status line" in the bottom part. That last text screen line can't be fully bitmapped as the remaining bytes ($1DC0..$1DFF + $1F00..$1FFF), 288 bytes, aren't enough: 22x16 = 352 bytes would be necessary.

Even with the text screen put to $1000..$10F1 and the character layout starting at $10 (similar to how MINIGRAFIK does things), text screen and bitmap would end up at 4128 bytes total, which just doesn't fit into $1000..$1FFF - the text screen would have to go to either $0000 or $0200, ending most hopes of a good OS interoperability. So, using the bottom 16 pixel rows as status line probably was the best bet.

From a quick peek into the *.d64 I'd assume the text body is compressed and you use some IFFL-like technique for quick seek into the files? The proportional font rendering engine is also quite nice. Any chance you show it here in the Programming section for discussion?

Greetings,

Michael

[bjonte]

From a quick peek into the *.d64 I'd assume the text body is compressed and you use some IFFL-like technique for quick seek into the files? The proportional font rendering engine is also quite nice. Any chance you show it here in the Programming section for discussion?

Similar to IFFL, I'm having code run in the background to load the first two bytes of each sector to determine every sector location on the disk, so that's similar, but I'm not trying to put everything in one file. After a while the disk reader is able to seek to any block and load it without much delay. The text is huffman encoded to compress it a bit and scrambled to allow any unicode character to be used in the source text and keep each character 8 bit wide.

I'll attach the font rendering code. It's a bit messy with the platform support and it's not easy to see how the font data is stored. But in essence, there's data for each glyph with bitmap and dimensions, with an optional kerning table. Rendering code is templated per byte width and it copies rows of bitmap to a temporary buffer and shifts before writing to the back buffer.