The Overcomplicated VIC-20 IRC client

N

NixZiZ

Limp Gawd
Joined
Dec 30, 2013
Messages
159
Hi! I have a VIC-20. And I'm going to turn it into an IRC client.
There'll be a lot of documentation here, but I expect a lot of the technical details to be moved to an external blog in the future as to not have multi-thousand word postings.
Consider this a "day to day" thread, other than this post -- if you only want the nitty gritty architectural stuff I'd recommend looking at the blog, which doesn't actually exist yet since I have no content for it yet, and this part will be updated in the future with the link.

FAQ:

"Why don't you use a raspberry pi?"
You spelled pie wrong. You're telling me this can run IRC?
IMG_5884.jpg

Image shamelessly stolen from https://cosmocookie.blogspot.com/2011/10/raspberry-pie.html

"Why?"
Because using IRC on a computer from 1980 is pretty cool.

Ok, now for the actual post...

There are many architectural limitations to the 6502 and the VIC-20 hardware itself which will make this project painful and overcomplicated. And I have set some "rules" for myself:

  1. All external circuitry must be designed, prototyped, and soldered by myself (I'll spare myself the pain of custom PCB manufacture, and IC development -- I'm not going to design an ethernet PHY, for example.)
  2. The limitations of the VIC-20 must be overcome WITHOUT modifying the internals of the VIC-20, and only the ports on the back may be used to modify the functionality.
    1. This is to ensure that the end goal of an IRC functionality cartridge may be available in the future, in a very, very limited, unsupported run.
  3. I am going to develop all software to be fully open-source with a permissive (BSD) license.
  4. External toolchains are permissible (I do not have to write the software in the 80s, I can use C compiled to a 6502 target with inline assembly where needed)
  5. External hardware faster than the VIC-20 is permissible
    1. However, it should be limited to where needed -- for example, not going to use an odroid instead of an ethernet PIC.
  6. The majority of the software MUST be written by myself.
    1. I understand there are OSes available for the VIC-20, some of which contain an IRC client. But that's not OVERCOMPLICATED, IS IT?!
  7. The cartridge must, in the end, contain everything needed: From memory expansion to ethernet to ROM, it simply must have it all!
Requirements of the software and hardware:
  1. Fully compliant with IRC protocol v2.4.0 documented in IETF RFC 1459
  2. Scrollback of at least 50 lines per channel
  3. 5 channels or more
  4. One or more IRC server connections (Starting with one with a view to keep the code scalable to have more)
  5. Support 10/100 ethernet
  6. Fully compliant with all applicable networking standards used in a home network
  7. Fully text-based client, with the only input device being the keyboard of the VIC-20

Alright! Now that that's out of the way... Let's talk DMA!
Yes, DMA on a VIC-20. I did say I'm making my own expanded memory controller... 5K simply isn't enough to handle all of the scrollback for all of the channels, let alone have the code in it!

Pretty much, due to the very limited address space of the VIC-20 (~ 64k!) we're going to need windowed memory more than likely to handle this. And because getting things in and out of the (bitbanged) RS-232 would be... difficult, at maybe 2400 bits a second best case, DMA seems like a more logical answer. I will use the GPIO for window selection (Remember, need more than just the chip select for that!), various DMA control (undecided exactly ~how~) and other assistive functions, instead of using them to get a slow, stupid serial input/output.

Additional architecture to come with time.

Hardware to be used beyond a VIC-20
I expect to use two small microcontrollers (likely microchip PIC controllers or other TI/ST controllers) to handle the expanded memory, windowing, and the TCP/IP stack. One for the memory system and DMA handling, and the other one to run the IP stack.

IP stack stripping and processing is to be done entirely in a microcontroller. the 1500 byte MTU is just too big, I think, to eat entirely on a VIC-20 in any remotely efficient manner. I want to just get the IRC protocol to it.
I hope to find a microcontroller with an integrated ethernet PHY as that will make my life easier.

The memory handling was already discussed earlier.

The VIC-20 will handle the entire IRC protocol. Software architecture hasn't been defined yet.



What are your thoughts so far? Am I completely nuts?
 
Last edited:
Did you happen to mean IRC server 'cause... IRC client, that just seems a bit, ordinary?

As for the question of whether you're completely nuts or not, no, not nuts, more like batshit crazy fucking insane might be more applicable, sure, but if this is what provides you with some enjoyment, who are any of us to say otherwise? :D
 
Last edited by a moderator:
Tiberian said:
Did you happen to mean IRC server 'cause... IRC client, that just seems a bit, ordinary?

As for the question of whether you're completely nuts or not, no, not nuts, more like batshit crazy fucking insane might be more applicable, sure, but if this is what provides you with some enjoyment, who are any of us to say otherwise? :D
Click to expand...

I'll be honest: The IRC server is easier due to reduced memory requirements. It doesn't need scrollback, logging, etc, like a client would. Maintaining the state of a few users is again, relatively trivial: Each user has a list of what channels they're joined to, you get the incoming messages, look through the users to send to the right users, etc... there's relatively little buffering needed.
Because of the 50 line scrollback requirement, the IRC client is more complex, requiring windowed memory since I want 10 channels. It would have to maintain channel status, various flags, etc, but those can be simplified some and you can implement limits to maximum channels, etc...

Also, the VIC-20 is fucking slow, which, for an IRC server, isn't very fun to use. I can use an IRC client, but a fucking slow IRC server that likely wouldn't be fully-featured with various network services doesn't seem quite as useful as a client.



I suppose I am a little nuts. I've kind of engineered the requirements to make it difficult to do on such old hardware performantly -- and nevermind having enough RAM to hold all of the text!
In fact, with a 50 line scrollback over 10 channels, and given each IRC message is up to 512 bytes long, and 10 channels of 200 bytes size (as per the RFC)... that's > 256K of ram for the SCROLLBACK ALONE, which is... 4 times the address space, and 8 times the normal user-accessible address space! (approximately...)

OK, admittedly, that's KB, not KiB, but it's close enough...
Maybe I can write the IRC server in the future, though. It might be interesting to do.
And remember, the truly insane is hidden deep in the ordinary...


I have no life, so I'm going to be reading the VIC-20 programming reference (actually, I finished the machine language section, the memory map was very useful!) and ensuring I understand the cartridge memory expansion addressing before I start a proper architecture.
Naturally, this should be done by tomorrow or the day after. I -SAID- I have no life!

Edit note: Edited because I forgot a greater-than sign.
 
Great. I almost certainly will need to handle the memory management in the IRC client itself. The KERNAL definitely will shit the bed with a windowed expanded memory setup, and it's not like a compiler will "know" the weird memory map and paging...

That's fine. I'm going to have to write a routine inside the program to deal with reads and writes to/from memory. However jumps are pretty expensive in terms of cycle time, so I'm guaranteed ~15 cycle read/writes to memory, and for paged memory, 20 cycle read/writes if the page needs to be switched to access the data.
Thankfully, because the data is static, I'll be able to have a STATIC memory map with a basic LUT instead of having to maintain some kind of dynamic index.

Here's a refresher, from the Programming Reference Gruide of the VIC-20, of the VIC-20's memory map:

Code: 
     Decimal                                         Hex
     0       +----------------------------------+    0000
             | Working Storage                  |
             | RAM                          1K  |
     1024    +----------------------------------+    0400
             | Expansion RAM                    |
             |                              3K  |
     4096    +----------------------------------+    1000
             | User BASIC                       |
             | Program RAM                  4K  |
     7680    +----------------------------------+    1E00
             | Screen RAM                       |
     8192    +----------------------------------+    2000
             | Expansion                        |
             | RAM/ROM                      8K  |
     16384   +----------------------------------+    4000
             | Expansion                        |
             | RAM/ROM                      8K  |
     24576   +----------------------------------+    6000
             | Expansion                        |
             | RAM/ROM                      8K  |
     32768   +----------------------------------+    8000
             | Character ROM                    |
             |                              4K  |
     36864   +----------------------------------+    9000
             | VIC Chip                         |
     37136   +----------------------------------+    9110
             | I/O-0                            |
     37888   +----------------------------------+    9400
             | Color RAM                        |
     38912   +----------------------------------+    9800
             | I/O-2                            |
     39936   +----------------------------------+    9C00
             | I/O-3                            |
     40960   +----------------------------------+    A000
             | Expansion ROM                8K  |
     49152   +----------------------------------+    C000
             | BASIC ROM                    8K  |
     57344   +----------------------------------+    E000
             | KERNAL ROM                   8K  |
     65535   +----------------------------------+    FFFF

              Figure 3-5. VIC20 memory locations.
Source: http://www.jeffrika.com/~malakai/vic/vic20prg_en.txt with a concatenation.

So, the plan is for:
Windowed expansion RAM controlled by I/O-2 (low addresses), and POTENTIALLY, IF NEEDED, a Windowed expansion ROM controlled by the higher couple of bits of I/O-2 (Entire 8k window moves after initial copy into memory) -- load the memory management/display/other essential functions into the 3k expansion, 4k prog ram, and the first 8k expansion ram, then use the upper two blocks of expansion RAM to act as the windowed memory area, for a 16k window size.

So, the map to my program will be:

Code: 
          Decimal                                         Hex
     0       +----------------------------------+    0000
             | Working Storage                  |
             | RAM                          1K  |
     1024    +----------------------------------+    0400
             | Low Prog RAM                     |
             |                              3K  |
     4096    +----------------------------------+    1000
             |                                  |
             | Program RAM                  4K  |
     7680    +----------------------------------+    1E00
             | Screen RAM                       |
     8192    +----------------------------------+    2000
             | Prog RAM                         |
             |                              8K  |
     16384   +----------------------------------+    4000
             | Window buffer 1                  |
             |                              8K  |
     24576   +----------------------------------+    6000
             | Window buffer 2                  |
             |                              8K  |
     32768   +----------------------------------+    8000
             | Character ROM                    |
             |                              4K  |
     36864   +----------------------------------+    9000
             | VIC Chip                         |
     37136   +----------------------------------+    9110
             | I/O-0                            |
     37888   +----------------------------------+    9400
             | Color RAM                        |
     38912   +----------------------------------+    9800
             | Control I/O reg                  |
     39936   +----------------------------------+    9C00
             | I/O-3                            |
     40960   +----------------------------------+    A000
             | Windowed ROM                 8K  |
     49152   +----------------------------------+    C000
             | BASIC ROM                    8K  |
     57344   +----------------------------------+    E000
             | KERNAL ROM                   8K  |
     65535   +----------------------------------+    FFFF
Since this hardware and code will be specific for this IRC client, I don't see any reason to use a standard memory mapping that might fit a little less well.
24 bytes for the I/O control area will be more than sufficient. If I need that many bytes for the window select, something has gone wrong OR I might be expanding past 2^192x16k of RAM -- which is pretty unlikely.

This means I can use this I/O space to handle most of the various locking needed and I don't need to worry about any direct line holding -- which I'm not sure is even possible on the VIC-20, actually, but I don't truly know yet.\

And having this memory map also means I can start to look at what I need to do to get that 16k window working! More details in another post...
 
Last edited:
You must log in or register to reply here.
Back
Top