O.K.bjonte wrote: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.
IEC serial output bits
Moderator: Moderators
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: IEC serial output bits
Re: IEC serial output bits
Yes, on reflection you really are.
I politely suggested he reconsider.
Vic20-Ian
The best things in life are Vic-20
Upgrade all new gadgets and mobiles to 3583 Bytes Free today! Ready
The best things in life are Vic-20
Upgrade all new gadgets and mobiles to 3583 Bytes Free today! Ready
Re: IEC serial output bits
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.
-
- Vic 20 Enthusiast
- Posts: 160
- Joined: Wed Feb 24, 2021 11:32 am
- Location: NC, USA
- Occupation: Engineer
Re: IEC serial output bits
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.
Re: IEC serial output bits
Yesterday this was released to the public. Not that useful if you aren't speaking Swedish though.
https://csdb.dk/release/?id=226955
https://csdb.dk/release/?id=226955
- Mike
- Herr VC
- Posts: 4845
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: IEC serial output bits
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
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
Re: IEC serial output bits
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.Mike wrote: ↑Sun Dec 25, 2022 5:19 am 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?
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.
- Attachments
-
- font.zip
- (8.71 KiB) Downloaded 33 times