Tonight, I managed to get a test program running to check the functionality of the Multicolor Character mode. Using the export files from CharPad where I created the background screen, I was able to get the program to load these files properly and display the background screen perfectly. It took some extra work to finally convert that multicolor bitmap screen. But that’s because there isn’t really a clean or smooth method for converting between these two formats because of the color limitations. the current color scheme will get us going for now so we can finish the game code.
CharPad actually has you export several files from your design. But the documentation provided is a little ambiguous. It spends effort describing these extra features within the tools while the existing method is already what’s possible using the available export files. I had already made a test program using the original method for loading a screen using Character graphics mode. And I found out, after all, that the same method can be used with the export files from CharPad — besides what’s described in their docs. As you’ll see the test program, it’s using the same method as before – nothing fancy going on.
When exporting files from CharPad, there is a Character Set file which contains the Custom Characters and Tiles – which you can also create inside this tool. I used only 1×1 Tiles in this design. I have the test program load this data at addr $D800. Then a Map file which contains the Screen codes for the Screen Memory at addr $400. Also a Tiles Map and Attributes Map. At the moment, there is no need for these last two files. I’m trying to find more information as to what advantages there are to using these lookup tables. From what I see so far, you can make use of these to change the screen codes within the screen memory during runtime. Now back to the game code……
While changing direction with the graphics mode options, – hopefully for the last time – I’m using the CharPad tool now together with the Timanthes tool to organize the background screen using Multicolor Character graphics mode. One of the things I found out this past week is that the Timanthes tool doesn’t properly convert that background screen I made last time using Multicolor Bitmap mode, I tried to convert that into a Multicolor Character mode. Even though you can change Layer 2 in the Layer properties window from Multicolor Bitmap to Multicolor Character and re-save the project – it doesn’t warn you that your design is using excessive colors. So I continued to use the CharPad tool to build the new background screen. Below is the current view of the background screen with the cities and command tower.
Unless you plan to use raster splits – eventually I do plan on this – to increase the colors per raster line, then you only have 4 possible colors per cell [reference] So I took the Tiles that were generated by Timanthes from the bitmap screen – I mentioned in my last post - and loaded it into CharPad. I can then view the Tiles in the Character set. Even though the colors are not being tracked accordingly, since we’re converting into in Multicolor Character graphics mode, the basic view of the Tiles are manageable. Then I’m using the CharPad tool to recreate the same background screen by using the Tile map and assemble a new Screen map in this tool [insert screenshot]. Also some of the Tiles need further editing to improvise the limited color scheme. Next, I will have this exported into a file which i can load using another test program to check everything operates according to plan. [link to code]
The background screen is organized into several sections. The first being the view of your city with the Space Command right in the center. Next there is the command console below that view. This is subdivided into 3 sections as well. the center being the Radar view to see incoming missiles from the opponents on the network. The radar view shows the 8 players in the foreground. If one of them fires a missile, then it will be projected on that radar screen. As the missile approaches your facility, it will come into view on your screen. The left and right sections contains various information for your facility and game status.
It’s been a while since my last post, These winter nights can be a drag without enough caffeine. So it’s time for a ”coming up for air” to write another update, so to speak, on this network gaming project with my crime-fighting cohort, Jeff Brace (Arkaxow). One of the refreshing attributes to programming on 30yr old computers is knowing it’s limitations. No matter how many advances, mods or upgrades there might be from 3rd party suppliers, there will be always be the familiar restrictions when programming on 8bit computers such as the C64 or others.
The biggest concern, of course, is memory. The past couple of months we have been scouring the manuals and websites about several options on what method to use for the background screen for our current network gaming project. I’ve been coming up with options to create a new C64 background using one of the various cross-platform development tools called Timanthes. One problem with this is that there’s no ‘Help’ file to go along with this tool. So it took quite some time to dig up some info online thru various searches to get it to cooperate. Eventually I managed to successfully create a Multicolor Bitmap screen which i can load into the C64 [screenshot].
I wrote a test program to check the functionality on how to manage the memory mapping between the screen memory, color ram, etc [screen10.asm]. The bitmap screen itself requires 8KB of memory to hold the graphics display. I currently use bank0 for the VIC-II so this loads in at addr $2000. There there’s an additional amount of memory need for the various colors – since this is a multicolor bitmap (4 colors/2pixels) The horizontal resolution is cut in half but you get more colors in return. So there’ an additional 1000 bytes needed which is stored in the Video Ram at addr $0400 for color1 and color2 attributes. And there’s an additional 4KB for the Color Ram at addr $D800 for the color3 attribute. There’a one other color register in the VIC-II at addr $D021 for the background color (global attribute)
And so it appears that we keep running out of memory with the current graphics mode option. The Network library is rather large (13.8KB) – used to interface with the C64NIC+ cart – and so is the packet buffer space (21.4KB). So this keeps limiting our graphics mode option. No matter how I fiddle with the memory map for the game code, I can’t continue to use the multicolor bitmap graphics mode without running out of memory. For this next step, I’ll have to switch back to using Character Graphics mode in order to save space.
After organizing the *.d64 images for each instance of VICE running here, I managed to get 4 players to connect to the Server. There was one small moment of a gltich where player#2 didn’t connect completely. So I restarted everything and tried again. I suppose this is one of the pitfalls when working with UDP. I’ll have to investigate that another time if it becomes a bigger problem. In the meantime, I’ll have to add some retry mechanism so I do’t have to restart the VICE emulation.
Below is a screen shot of what I have so far. The screenshot shows the 5x instances of VICE running here. The larger VICE screen on the right is the Server. And the group of 4 instances of VICE on the left are the 4 players.
You can see on the Server screen the various status messages when each player connect. The screen scrolled off so you don’t see player 1 connection, but it did, since I connected with that player first. I changed the sequence a little. I added an extra prompt to ask when the player is ready to start the game. This also helps me monitor the status messages on the player screen as well, since it will pause at the “ready’ prompt before changing to the game screen.
Something I noticed just now. Even though I could get several instances of VICE to run on my PC using the same *.d64 file, it must have been using the same ‘ipconfig’ file from that image.
Even though I would run ‘Configure’ in the beginning for each instance of VICE, the ipconfig file was actually holding the network settings for the last instance of VICE only – which is last player !! You can see the player name and player’s IP Addr in the ipconfig file generated by the ‘Configure’ network tool.
I thought the game only needs to load the ‘ipconfig’ file just once in the beginning – which is true.. But i was running ‘Configure’ at the same time in each instance of VICE. So the ipconf file must have been getting corrupted when several instances of VICE were trying to save to the same ipconfig file. aarrrgghh
So now it looks I can skip having to hookup several PC’s to my network to run VICE. And I will make individual copies of the *.d64 image for the game eveytime I make a new build. –stay tuned !–
I’m starting to notice that glitch more often now. I have 4x instances of VICE running on the same PC. I wasn’t sure what was going wrong for a while. But then I saw the Server mysteriously connect with one of the Players as soon I started the Server. And that one Player wasn’t even running Duel yet !! I would only do a Hard Reset in VICE for each instance before I would load the next build of the game code.
So then I would restart all instances of VICE every time I loaded a new build, but I would experience some of the same quirkiness behavior. Some players would connect and others don’t, and then vice versa. It appears the VICE networking support may have a glitch with multiple instances on the same PC.
I think I have to get separate PC’s and run only 1x instance of VICE on each to test the game code. I have an old laptop I can dedicate to this. So I will stall have 3, including the C64 to test the game code. Where one is always the Server and I will have 2 players. But I’m looking around for another junker PC to run VICE so I can get 3 players to connect again.
Once I get the extra PC, I’ll use Wireshark to analyze the network traffic during the game. I’m hoping this quirkiness disappears once I try this.
I’ve been making progress on the multiplayer Artillery Duel. I’ve been discussing with Leif Bloomquist(Schema) for quite some time about his C64 network game, Artillery Duel, which he made several years ago. This happens to be the first C64 Network Game. I’m working with Jeff Brace(Arkaxow) in getting a multiplayer version running. We’re using the C64NIC+ cart from Retro Innovations. And I use the source code which Leif sent us. And this makes use of the TCP/IP stack for the 6502 called NetLib64. The code is built using the DASM assembler.
I have 4x instances of VICE running here, and it’s not getting that slow yet. Eventually i will try and get 8x instances running here to fully test the multiplayer options. I have one instance running as a server on Duel. I managed to get the other 3 running as players to connect with the server. The 1st VICE running as a Server is changed where it doesn’t play the game as before. At the moment, I have it sit and waiting on the “Listen for Announce Packets” screen.
And there I can see the status messages on the Server screen – eg, player name, player IP addr – when all the other players connect to the server. Then you get another confirmation that each of them have connected when all of the payers switch to the game screen.
One thing I noticed, one of the players had a glitch where it didn’t connect the first time. So I had to restart that one. I was thinking about adding an option to let you retry the connection within the game. So you don’t have to reload the game each time.
I just came across a really good website with free eBooks. The following links have ebooks in various categories. From old school to new, there’s various ebooks that might interest you there. Shall I say DOWNLOAD !!
A friend of mine from the Apple I Mimeo website, Mike Willegal, alerted us that a specific transistor may be in short supply. The normal production and stocking of MPS3704 seems to have stopped with major distributers. I showed Mike there are some suppliers out there which stock this part. however, the future availability of this transistor is unknown.
Here’s a few sources for this transistor which I found so far. I’m not sure about the date code.
Talon Electronics [VA] http://www.talonix.com/
I uploaded the DASM ver 2.20.10 cross-assembler. I find this to be a favorite for 6502 assembly. Even though it supports other microprocessors as well, such as the 6507, 68705, 6803, HD6303(extension of the 6803) and the 68HC11.