Friday, October 16, 2020

Total 4play - Leveraging Total Replay's amazing infrastructure


 
 
Total 4play is a hard drive based collection of arcade style games which have been modified to support digital joystick gameplay, specifically via the 4play card. This compilation has only been made possible due to an amazing bit of infrastructure, called Total Replay, which is what Total 4play is based upon.

Total Replay can be described as a menu selection system and compilation of Apple II games. Compilation sets of Apple II games have been done before but nothing comes close to having the features of Total Replay. To obtain valuable disk space other game compilations have, in the past, resorted to removing parts of the game such as the title screen to cram games together. In contrast, Total Replay aims to preserve all the original content. It uses relatively modern compression techniques and relentless byte saving optimisations to make up for the extra disk storage space needed. The software contains game help pages, original title pages, game demos, an intelligent game title text search engine, original box art where possible, a configurable cheat mode, Control-Reset feature that gets you back to the main menu, a quick loader and bug/compatibility fixes for certain storage media, memory and sound cards. These are just a few of its amazing features. In many ways this software is more than just a game compilation, it's a way to immerse one's self in retro gaming nostalgia but without all the annoyances of the era, such as compatibility issues and relatively slow loading times.

Version 1.0 of Total 4play has be released with twenty converted games. The majority of these games have already been converted to support the 4play. However, these conversions have been done on floppy disk images. There are several advantages to using the Total Replay infrastructure instead of using disk images. These advantages include :-

1. Better grouping of games in one easy usable format. Faster loading and switching between games. Seeing title screens and demos before starting the games.

2. Being able to use any slot of the Apple II for the 4play card. This was more difficult to achieve with individual floppy disk conversions.

3. Having information in the help page that describes which input format (keyboard, Apple II Joystick, Joyport or Gizmo) has been overwritten. Saving the need to look this information up from another source.

4. The second stage of the conversion process (the storage of the changes) is much simpler. In Total 4play this involves applying the changes to the game during the start up sequence where as with the individual floppy disk conversion this meant finding the right places on the disk to modify the code. Having code go across sectors or code that was duplicated multiple times on the disk or code that was compressed made the conversion difficult to perform.

You would have thought that after twenty or so conversions that the conversion process would get simpler due to reoccurring code. However, this has not been the case so far. Apart from the games that were sequels, the code has been different in every one of my conversions. It amazes me how many different ways something can be written in assembly language that performs the same function.

This project will be ongoing. The first round was to work out the infrastructure and get some experience in putting together the games where "stage one" of the conversion process had already been done. Therefore, these first twenty games might not be the best examples of where digital joystick gameplay shines. I missed including some games like "Boulder Dash II", "SuperPuckman" and "Super Taxman 2" because these games were not included in the Total Replay list. The next round of conversions is to work out how to include these into the infrastructure then work on games which make the most sense and the ones which I can still play with for hours on end ie "Snakebyte", "Mr Do.", "Hard Hat Mack", "Pooyan" etc.

Digital gameplay is not not for everyone. It does take away from that nostalgic Apple II experience but does bring that arcade experience closer to the home computer environment. Some people prefer playing games using game controllers over joysticks but my preference is for the arcade joystick, which in my opinion, adds another layer to the experience. For now my original Apple II joysticks have been put away and I'm happy to let other users play with the digital ones. These are much easier to replace.

A big thanks to everyone who made Total Replay possible and for your help in getting me started on my variant. I suspect that Total 4play is not going to be the last offshoot of this wonderful bit of infrastructure. It has the potential to transform many other gaming genres. Think "Total Adventure" or "Total Education". 

Total Replay: https://archive.org/details/TotalReplay

Development: https://github.com/a2-4am/4cade

Total 4play V1.0 (20 games): https://docs.google.com/open?id=17d16hsBl24g0zSSJQ15__4MLEvlPxneH

Development: https://docs.google.com/open?id=1p8x6HZQIU3Pl4gZ3UxQAX3_8uDRLZq_7

Sunday, August 23, 2020

Modern Monitor Solutions - Display Lag


Early home computers were built around the concept of using televisions for a source of display. As monitors became more affordable, monochrome and then colour monitors became the norm. These solutions rely on CRT technology but as time goes on it becomes harder and harder to support, in terms of replacement or in terms of repair. Numerous creative solutions have been designed and built to cater for an ever-increasing demand of CRT screen replacements. A lot of these conversions have focused on getting an image that is as close as possible to the CRT looking display. However, is this being done at the expense of other factors such as the display lag? Do you find it difficult to match that high score you got as a teenager on your favourite game? If so, then maybe it's not due to old age. It may be due to your monitor solution. I compared the display lag on several of today's solutions and I found mixed results.

For those enthusiasts using retro computers for word processing, programming, communications and hardware hacking, the display lag will hardly matter but for the retro gamer it’s an important factor to consider. Everyone will have a different perspective on how authentic they wish their retro experience to be. To some, having to replace their CRT display with an LCD solution would seem unthinkable while to others playing a game on an emulator is nostalgic enough. It will all depend on your time, resources, budget and your level of the "Obsessive Compulsive Disorder". Which is more authentic, playing on a cycle accurate emulator or a physical computer with a modern-day monitor? This is what I wanted to find out.


Frame strip showing a three frame (60ms) delay.

It's generally considered that a lag of 30ms on a display is not going to be noticeable. When you consider one screen refresh will take 20ms when displaying at 50Hz or 16.67ms when displaying at 60Hz then you hope your monitor is not going to have a lag of more than a frame or two. Even 30ms sounds quite a long time to me, considering today's LCD gaming monitors tend to advertise lag to be under 15ms. If you are sitting in front of a computer with just one monitor, then you're probably not going to notice any lag. I first noticed it when developing the A2 Video Streamer which sends video signals over USB to display on a modern-day computer. I wasn't surprised to find that sending video data over a USB feed was going to cause a delay but what I do find surprising is seeing large delays in some modern-day monitor solutions, especially on those that I assumed to have no buffering. Every monitor is going to have lag. Even a CRT monitor. However, the lag on a CRT monitor is going to be in the nanosecond range. For now, I just wanted to test the display lag using tools I had at my disposal. What I wanted to do was to compare a CRT monitor with other video solutions to see how much difference there was. I figured I could do this with a bit of programming and a device to record the video of two monitors side by side.

I started off by writing a simple program that displays a two-digit number at the start of each text line. The number is updated by one and rewritten to the buffer page every time a vertical blank happens. That way the number represents each display frame. Vertical blanking is a pain to write on the Apple II because it is done differently for each of these groups of models 1.Apple II/II+, 2.Apple IIe, 3.Apple IIc/IIc+, 4.Apple IIGS. Since the II/II+ code either requires a hardware modification, extra hardware or substantial amount of programming (specifically lookup tables), I left the code supported only by the computers I had on hand. That is all but the II/II+. Once the program was written, tested and running, all I had to do was to setup each of my computers (IIc, IIe and IIGS) with two monitors at a time and video the results. To do this I used an iPhone and two apps, ProMovie and MoviePro. These apps allowed me to use a predefined frame rate (~50fps and ~200fps for 50Hz). The iPhone seemed like a reasonable option for the accuracy that I was after.



The selected recording frame rate, using the iPhone, was not exact nor was it an exact match to the Apple II's output frame rate, but this did not turn out to be an issue. When looking at the video frame by frame, it allows you to see a scan line coming down the page very slowly. The scan line differences from both monitors can then be compared. Watching the recording of a CRT monitor shows the frame numbers changing over the scan line. However, the recordings of the LCD monitors are not as clear. The change is more gradual, and I suspect this is because filtering is being done to merge the video frames. This makes the comparison process more difficult.


Due to the slight difference in scanning rates between the IIGS and the Video Overlay Card (VOC) we get to see some interesting line updates.

The results are as follows. I will update this list as more test data becomes available.


Model Video 1 Video 2 Lag (Frames)
IIe Composite -> IIc Monitor (Composite) AIIE 80COL64K MEMORY EXPANSION AND VIDEO -> Sony PVM-9045QM Monitor (Composite) 0
IIe Composite -> IIc Monitor (Composite) AIIE 80COL64K MEMORY EXPANSION AND VIDEO -> Sony Portable CD/DVD Player DVP-FX720 (Composite) 0.5
IIe Composite -> IIc Monitor (Composite) AIIE 80COL64K MEMORY EXPANSION AND VIDEO -> Dell U2410 Monitor (Composite) 3
IIc Composite -> IIc Monitor (Composite) Apple IIc Video Expansion -> PAL Modulator Adapter -> Sony PVM-9045QM Monitor (Composite) 0
IIc Composite -> IIc Monitor (Composite) Apple IIc Video Expansion -> BeagleBoneBlackHDMI -> Dell U2410 Monitor (HDMI) 2
IIc Composite -> IIc Monitor (Composite) Apple IIc Video Expansion -> A2 Video Streamer -> PC Laptop Inbuilt Monitor (USB) 2.5
IIGS Composite -> IIc Monitor (Composite) Video Overlay Card -> Sony PVM-9045QM Monitor (RGB) -0.5 to 0
IIGS Composite -> IIc Monitor (Composite) Video Overlay Card -> Sony PVM-9045QM Monitor (Composite) -0.5 to 0
IIGS Composite -> IIc Monitor (Composite) IIGS RGB -> IIGS Monitor (Analog RGB) 0
IIGS Composite -> IIc Monitor (Composite) VidHD -> DELL P2719H Monitor (HDMI) 1
IIGS Composite -> IIc Monitor (Composite) VidHD -> HP P242va Monitor (HDMI) 1
IIGS Composite -> IIc Monitor (Composite) VidHD -> DELL 2407WFPb Monitor (HDMI) 1.5
IIGS Composite -> IIc Monitor (Composite) VidHD -> Dell U2410 Monitor (HDMI) 1.5
IIGS Composite -> IIc Monitor (Composite) IIGS RGB -> Dell U2410 Monitor (Component) 3

The frame counter disk image can be found here. https://drive.google.com/file/d/1pBeuZPA2ChLt88uoHg_weAUq-XgZ0STB/view

Friday, August 14, 2020

Game Controller - H.A.L. Labs Gizmo - Cloning the Cloner


In 1981 H.A.L. Labs released Taxman, a direct Pac-Man clone on the Apple II. Atari was not happy since they held the rights to Pac-Man so they asked H.A.L. Labs to stop selling the software. Atari took Taxman, changed the title and then went on to release the game as their own official Pac-Man for the Apple II platform. Not to be outdone, Taxman's developers re-created the game but this time they made sure that there were enough differences to keep it away from Atari's clutches. It was called Super Taxman 2 and in terms of game play, it was a big improvement. The ghost characters no longer looked like ghosts. The maze layouts were different. However, the running speed and the ghost artificial intelligence made it feel more like a real Pac-Man game.

In their pursuit of performance, the developers became frustrated with the slow speed of the Apple II's analog joystick. In response they created their own joystick solution. They built the Gizmo, which is an adaptor that allows you to use digital joysticks on the Apple II so long as the software is coded to detect the special hardware. In Super Taxman 2 there is no support to play using the Apple II Joystick. It's either the keyboard or the Gizmo. Some levels are so fast it's barely controllable. Try level 88 and you'll wonder if you are playing on a standard Apple II or if you're running via an accelerator.

It was the Gizmo adaptor which interested me the most. This adaptor allows a single digital joystick to be connected to the Apple II and be able to control specific software titles. I could only find two titles which have been adapted to use the Gizmo, Super Taxman 2 and Vindicator (a Robotron clone) also released by H.A.L. Labs. I was unable to locate any information on the construction of the Gizmo so I headed in the only direction I had available to me and that was to reverse engineer the hardware from the software. My investigation led me to conclude that the Gizmo works in a similar way to the Atari Joyport (http://lukazi.blogspot.com/2009/04/game-controller-atari-joysticks.html) which is also an adaptor that allows digital joysticks to be used with the Apple II. However instead of multiplexing the Apple II game port's annunciator output onto three of the push button lines the Gizmo multiplexes the game port's three annunciator outputs onto a single push button line.





To test my assumptions, I put together a board and luckily it worked first go. Here is the schematic for the Gizmo and the truth table used by the software. I'm sure that H.A.L. Labs being in the business of cloning (not all their software titles mind you) are not going to pursue me for recreating their hardware. If the hardware had taken off then doing this back in the day may have been a different story.

If you fancy getting that high speed digital joystick experience without having to go through the pain of creating an adaptor for just two software titles then you will find that I have modified the games to work with the 4play card (http://lukazi.blogspot.com/2017/08/apple-ii-4play-joystick-card-software.html). Since the Gizmo only supports one trigger button it's a pain to play the game Vindicator. This game contains two fire actions (one for shooting and one for the screen bomb). Having to use the keyboard to access the screen bomb annoyed me greatly so in the 4play conversion the screen bomb is mapped to the second trigger button. This makes playing the game much more enjoyable.

Tuesday, August 21, 2018

Apple II 4joy - Serial interfacing through the game port




The Apple II 4Joy is an adapter that lets you connect four digital joysticks to the Apple II via the game port.



In my last blog I looked at running a digital joystick interface via the IIc's serial port. Technically I wasn't correct in saying that the serial interface is the only available option for communication on the IIc. Obviously there are other options such as the floppy disk interface, the keyboard interface and the game port interface but these are most likely already being used for dedicated functions. The game port however can be used for general communications but it's only unidirectional. In our case this is enough to get by on. I evaluated a few methods of communicating using this interface.

Method 1: The first method I looked into involved transferring a byte of information by generating a resistive circuit that mimics an Apple II paddle / joystick axis. This could be done by outputting eight digital lines from the microcontroller and switching parts of a resistive ladder to form the zero to 150k ohm resistance range needed by the Apple II. Alternately an extra chip such as the AD5206 could be used to generate the resistance. This method would require multitasking to put through four digital joystick status bytes over the IIc's only two paddle lines and each Apple II would need to be tuned because the game port's analog circuit contains discrete components that vary slightly from one machine to another. The other factor is that reading analog values via the Apple IIs games port is very slow. Even if the format is modified to be limited to a low analog value I estimate it would still take about 2000 microseconds to read, process and store the four joystick status values. This method is not preferred for serial data communications.

Method 2: This method involves running digital signals though the analog paddle lines. Each analog port would be reduced to a value of zero ("False") and non-zero ("True"). Reading an analog value from the paddle port takes about 4 microseconds if the value is zero all the way up to about 3000 microseconds if the value is 255. If the data is digital then we can read the port after 4 microseconds and get an answer straight away. This translates into a transfer rate of about 200 microseconds per byte instead of up to 3000. Most Apple IIs have four paddle lines (PDL0, PLD1, PDL2 and PLD3) so we could send though a nibble of data at a time (this is not as great as it sounds because you still need to read each bit at a time). The push button lines could be used to handle the synchronisation. The software would require some overheads in putting the two nibbles and the format back together but this would be straight forward. The hardware would require something like a 4066 chip to switch each analog port from 0k resistance to about 1.5k or greater. This should result in enough time to read all four analog ports and determine if each is "True" or "False". The IIc however does not have PDL2 and PLC3 lines. These were removed to make way for the mouse interface. Instead these lines are TTL compatible digital input lines (XDIR and YDIR). We don't need to change our method by much because we are already dealing with digital signals. The only change needed would be to add a toggle switch which allows the microcontroller to connect to XDIR and YDIR directly on the IIc or to the 4066 chip for non-IIc Apples. The result of all this would be to have all four joystick status bytes sent over in about 1000 microseconds. This is not a bad solution but can we do better? 

Method 3: The last method I looked at was to send a serial stream of bits though the game port's push button lines. One push button would be used for data and the other would be used for synchronisation. It's unlikely that the microcontroller's clock rate will be a direct multiple of the Apple II's clock rate so synchronisation needs to happen quite often, possible once every byte. A byte could be sent through in under 100 microseconds. The software would be relatively simple (simpler than the above methods). The routine to do the synchronisation, data transfer, processing and storage would not be as compact as running data through the serial port but should result in a much faster transfer rate. With this setup the hardware becomes simple too. Only the microcontroller is needed and a few discrete components. The result of all this is being able to transfer the four joystick status bytes in around 500 microseconds.

Once I looked at method three it was clear that this was going to be the best option to tackle. A good amount of the work was already done in the serial port project so I reused as much as I could. In terms of hardware the TTL to RS232 converter was removed and in its place I added a small breadboard with the DE9 pin plug, some discrete components and some headers for testing. This project was all about getting the software right which meant timing was critical and counting cycles on the Apple II as well as the microcontroller was needed.


Showing microcontroller output is too fast and then after delays have been added.

The first step was to write the fastest read loop on the Apple II. After obtaining a few pointers from Michael's NadaNet project, I was able to nut this out. This was going to be the bottle neck since the microcontroller was capable of outputting data much quicker than the Apple II could read it. The microcontroller code was written to stream a sync signal followed by an eight bit byte for each joystick. The dilemma now was how to view what the microcontroller was outputting and compare that to when the Apple II was expecting a read. The timing was sub-microsecond critical and the Apple II was reading (inputting) signals and not outputting them. The easiest thing to do was to move the development from the Apple IIc over to the Apple IIe. What this allowed me to do was to take a copy of the code, change the read instructions into write instructions but at the same time keep the cycle timing the same. These write instructions were then sent to the IIe's 16pin game port output (annunciator) pin. By adding this output to the logic analyser I was able so see exactly when the Apple II was going to be performing a read operation. I could then tune the microcontroller outputs to match the requirements of the Apple II.

Since the joystick number was going to be extracted from the data (just like in the serial port version) there was no need to synchronise starting at a specific byte. So long as four bytes were read in a row it did not matter which joystick status byte was read first.

In tuning the interface there were several critical points to get right:

1. Apple II read pulse length.

To get the microcontroller to match the Apple II, read pulse lengths measurements from the logic analyser were used and delays were added in the appropriate places. The faster the microcontroller can be run the more resolution is available to match the Apple II. Since one speed is not a subset of the other then the best we can ever do is an approximation.

2. Sync pulse length.

The Apple II code that checks for the sync pulse is seven cycles long. Therefore the sync pulse length needs to be at least seven cycles long but less than twice that.

3. Time between bytes.

Once the Apple II has read a byte of data the microcontroller needs to pause for while until the Apple II catches up with processing and storing that data. For this project that amount was roughly forty five microseconds.



We can see from the above screen shot that if the sync pulse is too short or if the delay between bytes is too short then a gap is generated between the joystick status bytes. This condition would be too short to affect any game play but it is undesirable and easy to eliminate by performing more tuning.

4. Time between the start of sync and the start of first read.


These screen shots show how much the time between the start of the sync pulse and the start of the read pulse can vary.

The last critical point was to fine tune the time between the start of the sync pulse and the start of the first read. This is where all the fun began. This start time variance is determined by the length of the sync check.

The sync check takes seven cycles to execute and looks like this

LOOP CPX $C061 - 4 cycles
   BCS LOOP - 3 cycles on jump

however the initial read loop takes six cycles and looks like this

   CPX $C062 - 4 cycles
   ROL - 2 cycles

Therefore the read pulse is going to be shorter than the variance of the start time. In other words this is not going to work. The read pulse needed to be extended. The longer the read pulse is, the less significant the start time variance becomes but also at the same time this slows down communications. By adding just one extra delay into the read loop it takes the cycle count to eight which is larger than the sync check.

Even though the sync check pulse is now less than the read pulse when you take into account that the microprocessor timings are not directly linked to the Apple II clock, this becomes our border line condition. I can get communications working at this speed but it's not stable. It can be tuned to a given computer but the aim is to have the device working on any Apple II computer. This translates into a communication rate of around 80kbps. This includes reading the data, processing the data (extracting the joystick number) and storing the data.

Testing for stability was quite easy to do. The microcontroller was setup to transmit a specific byte. The Apple II side was setup to read this byte and if it was different from what was expected then a counter was incremented. As the timing was adjusted on the microcontroller you could see the rate at which the counter was ticking over slowed down until it stopped counting. It had reached stability.

To make the interface stable I ended up expanding the read loop, not by adding an extra NOP instruction but by making the read routine into a loop (instead of just having the same read code duplicated for every bit). This resulted in a read pulse of eleven cycles but it makes the code a lot shorter. A good compromise in my book. This translates into a communication rate of around 60kbps which is still six times faster than reading analog data or several times faster than what I was able to achieve through the serial port. For processing joystick data it is still an overkill.

At first I thought that running communications over the two game port push button lines would be the perfect solution especially in making a device that would work on all models of the Apple II. Well it didn't turn out as straight forward as I had hoped. These were the issues:-

1. Apple added filtering capacitors to the Apple IIe platinum model so I suspect the 4Joy in its current setup will not work on this machine. Without removing the filtering capacitors the only option would be to slow down the communication rate. I don't have one of these models to test on.

2. I've had mixed results trying to get these high speed communications going over the push button lines on the Apple IIc. Sometimes it works but then other times it does not. I suspect this is to do with the resistor pack on the IIc's game port interface. I tried replacing the general signal diodes with ones that have a lower breakdown voltage however this made the timings worse. On the IIc I found that diverting the communications from the PB0/PB1 pins over to the XDIR/YDIR pins bypasses the resistor pack and makes the interface work very well (similar to my tests on a IIe and a IIgs). The other option would be to slow down the communication speed.

3. The game port push button pins (PB0 and PB1) on some Apple II models are tied into the reboot function and the self-diagnostic function. Since the sync pulse on time is much less then the data on time I swapped my PB0 with PB1 signals so that the probability of starting the self-diagnostic function on a control-reset is very low. It does happen occasionally but I get around this by doing a second control-reset. However this means that the probability of getting a reboot from doing a control-reset is quite high. I prefer it to be this way around than the reverse.

The next phase will be to add USB support and combine it with the "Bluetooth Game Port Receiver". With a flick of a switch it should be possible to swap from being a single USB/Bluetooth analog joystick receiver to a multi USB/Bluetooth digital joystick solution.

All the project files are contained here. https://docs.google.com/open?id=1CGB9NA_eKHfWACUQh_alhHitOMYklRSN

Wednesday, July 4, 2018

Apple II 4serjoy - Gaming through the serial port




The 4Serjoy is a device that allows you to connect four digital joysticks to an Apple II computer using a serial port.

With the release of the 4Play card, the Apple II models now have a great option for multiplayer gaming using digital joysticks. But what about the poor ole Apple IIc, the slotless Apple II? Having a slotless Apple II is like having your arms and legs chopped off. It really limits the expandability of the machine. Any interaction with external devices is reduced to what you can put through the serial ports. Some IIc motherboard revisions allow special expansion cards but I'm talking about compatibility on all IIc systems. Not only did the IIc have to contend with not having any of the standard Apple II expansion slots but existing functionality, that a hacker would come to expect, was removed in the name of compactness. This includes the 16pin game port (which was more than just a dual analog joystick port) and the second joystick port which made way for the mouse interface.

So what options could there be for multiplayer joystick control on the IIc? Well, like I said, the interface is limited to the serial ports. I wondered how well games would perform if having the joystick control flow through this interface. Would it even be feasible to begin with? I did some rough calculations. The maximum time for the Apple II's analog paddle read to reach stability is just under three milliseconds and all the paddle/joystick reads are in parallel so that's still three milliseconds. Now for the serial port solution. At 9600 baud in a typical N81 setup, 8 data bits, 1 start bit and 1 stop bit results in a transfer rate of about 960 bytes per second or one byte every millisecond. Four joystick bytes should work out to four milliseconds. A baud rate of 19200 should yield a time of about two milliseconds for four joysticks bytes. The serial times seem like they are on par with the analog circuits. Therefore if the overheads are small I figured that this was certainly possible. That was enough for me to proceeded with the challenge. 



The hardware comprises of an ATmega1284P microcontroller, a breakout board and a "Serial TTL to Serial RS232" converter. For the software I started off by using an existing 4Play modified multiplayer game. Using an already converted 4Play game saved me time because the analog joystick/ keyboard handler to digital control was already done. I didn't have any four player games so the closest I could find was Mario Bros which is a two player game. The microcontroller can handle reading four joysticks but only two are currently hooked up. I threw together a simple assembly program to test the serial stream.



The way this device works is that it uses the microcontroller to read the digital signals from four joysticks (four direction positions and two fire buttons per joystick). This information is encoded into four bytes that is similar to the 4Play protocol. The four least significant bits are kept the same (direction signals), the two most significant bits are kept the same (two fire buttons) and the remaining two bits now encode the joystick number instead of the 4Play card identifier (bits 00: joystick 1, 01: joystick 2, 10: joystick 3 and 11:joystick 4). These four joystick status bytes are continually streamed to the Apple II via the serial port. Software running on the Apple II reads these values and replaces the existing direction commands that came from the game port / keyboard with the new digital signals.

The biggest issue with this setup is the need to modify the original software. The software needs to be modified to read the serial port instead of the game port or keyboard. This is a lot more work than modifying software to handle the 4Play card. Unlike the 4Play card which uses up less code then the original software (when hard coding the card's slot location ie not using the 4Play identification bits) the 4Serjoy needs to find space for 1. Serial port initiation (roughly 15 bytes), 2. Routine to read the serial port and store the joystick status bytes (roughly 25 bytes), 3. Storage of the joystick status bytes (4 bytes), 4. Call to the serial processing routine (roughly 20 bytes because there are multiple calls per loop) and then 5. As per the 4Play card you need to change the existing joystick/keyboard handler to use digital signals.



Apart form the usual great tools that I use to put together a project like this, having Hex Ray (a part of Nick's Virtu Apple II emulator) was a life saver. It allowed me to work out which parts of the Apple II memory were free to add in all the extra code that I needed for this game. Mario Bros is a resource hungry game so it wasn't easy to find available space.

Within the Mario Bros game there is a loop in which the joystick/keyboard handler gets called. When adding in the new call for the "check serial port" routine I found that every now and again the trigger button would not register. This seemed reasonable because there are four joystick status bytes to transport and checking one byte each loop means that a single joystick will only be read once every four loops. I added a second call to the loop however this did nothing to fix the trigger button issue. The problem was that the calls were too close to each other. By placing multiple calls within the loop and placing them further apart made all the difference. This means that joysticks 1 and 2 are being read every odd time through the loop and joysticks 3 and 4 every even time. This produced the game play that I was expecting.

My first lot of testing was using the default baud rate of 9600 but I wanted to know how the buad rate affected signal lag so I setup the system with baud rates 19200, 9600, 4800, 2400, 1200, 600 and 300. I had a preconceived idea that the game would not work below 9600 but I found that having baud rates between 19200 and 1200 did not change the game play enough for me to notice a difference. Maybe on a different game the lag would be more noticeable at the lower rates. Mario Bros is more of your "get the timing right" then a "test your reflexes" type of game. However the lag was obvious once 600 baud was used and 300 baud was even worse. What surprised me the most was that the lag was pretty bad at 300 baud but the game was still relatively playable. Using this baud rate I still managed to complete the first five levels without a problem. I could have continued playing the game further but the lag was annoying the crap out of me. This shows that the positioning of the code to read the serial port within the game loop is far more critical then the baud rate.

I built this device to full-fill the problem for the IIc but it will work just as well on an Apple II/II+/IIe (with a serial card) and the IIgs.

There are a few small changes I would need to make if I was to get this product up and running. These includes adding in the resistors to make it compatible with the Sega Genesis (Maga Drive) / Amiga CD32 type controllers and turning off the JTAG fuse on the microcontroller to free up port C which would then allow the connection with four joysticks instead of two.

Even though I don't see much of a demand for this device it answered a few of my questions and with surprising results. However on the rare chance that a landslide of multiplayer games becomes available for the Apple II then I know I'll be ready to go.

All the project files are contained here. https://docs.google.com/open?id=1m-IbGrzWqj3kRNCGpvAYJO-W6phvg0IZ

Tuesday, August 22, 2017

CHECKPOINT




CHECKPOINT is based on classic arcade style driving games where you go from point A to point B via checkpoints and do that within certain time restrictions. However, unlike the typical driving game which is computer generated, CHECKPOINT relies on the user driving a real vehicle, not a full-size vehicle although it could be done but a remote-control toy vehicle. The camera feed from within the vehicle results in the game screen showing the driver's perspective as it speeds around the track. The aim of this project was to take the user back to a time of remote control cars, slot cars and train sets, a time when a kid would dream about having a conversation with talking Pontiac Trans Am, time travelling in a Delorian or jumping a police car in orange Dodge Charger.



It was four years ago that I was trawling through ebay looking at Apple II related items. It made my day when I came across a hidden gem lurking amongst hundreds of generic items. The ebay listing was a complete set of items that formed an Apple II based remote-control car controller. Included in the listing was a commercial branded (Heuristics) relay board, software in the form of a cassette tape, a modified hand controller and a LaTrax Alpha RXC remote-control car from 1978. At first, I thought that this was one commercial product due to the Heuristics stickers plastered over the car and hand controller. It didn't take me long to realise that this was actually two different products. This is an amazing set and to me it represents the early days of computer control in the form of a toy project.




Toys are often used to display principles that later become life changing events. Take the Aeolipile (Hero's Engine) for example. It was developed around the year 100 AD and it show cased principles of steam power. It wasn't until the 1500s that steam engines became useful and the 1700s that steam power helped drive the industrial revolution. I found this ebay listing fascinating and I consider it a great example of early computer control with telecommunications. In just a few decades these principals have radically changed the world I live in compared to the world my parents grew up in. I can imagine someone seeing this set operational in the late 70s and wondering what their future had to offer just like I watch science experiments today where super conductors are suspended in mid air and wonder what the future has install for me.

I would have loved to have purchased this great bit of history however the price tag of nearly AU$1000 was a touch above my budget. Realistically I could have purchased it but I just couldn't bring myself to do it. I'm not a museum. I'm a tinkerer and the concept fascinated me more than owning the equipment. What stumped me from the listing was how many pins were being used between the relay card and the hand controller, seven in total. For controlling the car (four controls are required - Forward, Reverse, Left and Right) so I would have guessed that five or eight lines may have been needed but seven? This seemed like a strange number to me. To satisfy my curiosity I contacted the seller and requested more information. The seller provided me with a photo of the underside of the board and gave me some background as to where this set was being used. It turns out this set was being used in a car dealership as a conversation starter. I can just picture the sales person now, saying "Here are the keys to your new car sir. Next time you purchase from us we may have a car that will drive you home." I had a chat to the seller and we discussed how this set could be made functional again. I don't recall if the seller had an Apple II but they certainly didn't have a cassette player.

After tracing it out it all made sense.

Now that I had information on the relay card I wanted to see if there was anything special about the software. Obtaining the software from the seller's original cassette tape was not an option. I knew that Brutal Deluxe Software had an archive of Apple II cassette tape images so that was my first point of call. Unfortunately, in this case they didn't have the tape I was seeking. But that didn't stop me from checking the website every few months. About a year and a half later I checked once more and to my surprise there it was. Wow, how often do you get to find something so obscure and rare. I took the wave file and ran it through CiderPress to obtain the program. Reading the program confirmed my suspicions that there was nothing fancy going on. One just needed to poke the first byte of the card's address memory with the byte containing the appropriate bits that corresponded to the four relay switches. The program was written in Basic and was used to select a group of preconfigured movements. These preconfigured movements would then be sent to the relay card which controlled a toy car or robot or anything else that could be controlled with a few switches. Even though I didn't find anything useful in the program I found the programming style very interesting. This was early days of home computing and the style very much represented that.

Stuck with this information I wanted to reproduce something similar to this set. What I needed was to get my hands on a remote-control car. I could have popped down to the local shops and picked up a generic remote-control car however interfacing to it may have been a problem and it just would not have been inspiring enough. I decided to track down something more attune to my childhood. I had other projects to work on so it took a year or so before I found something that was affordable and would suit my purposes. The purchase was for two Hitari built remote-control cars (KITT and the General Lee). I figured that this would give me plenty of spare parts, the electronics would be through hole and easy to work with and if I could work out a way of changing the frequency on one of the cars then I could incorporate both cars into the project.



While waiting for the cars to arrive I built and tested the relay card. This relay card is based on the Heuristics one but contains eight switches instead of four and can be easily configured for different connection scenarios (to my LEGO robots). The cars arrived and I configured one of the hand controllers to the relay board. These cars have digital control circuitry (compared to the LaTrax Alpha RCX which has analog) so the wiring to the relay board is different. The Hitari cars also have six controls instead of four. The extra two are for the horn and the second forward fast speed. A simple basic program was written to take the Apple II joystick movements and use them to control the remote-control car. All this went smoothly and to plan.



Playing with the Apple II and the toy car was good for about five minutes. After that other pastimes looked more interesting. This may have been a spectacle in 1978 but in 2017 it's old hat. I had to find a way of making this more interesting and since OzKFest was only a few months away I wanted something to present that wasn't going to be outdone by the likes of Jason and his LEGO Cannon. Jason's LEGO Cannon is an Apple II controlled firing device constructed from the Boulder Blaster 70747 Ninjago LEGO set and using the LEGO TC Logo parts for movement control. A pinhole camera is used for targeting. Jason presented this at the last OzKFest event.

I decided the best way forward was to make a game out of it. Hence CHECKPOINT was born.

The first enhancement step was to add a video feed to the car. This was done by purchasing a miniature camera and a composite transmitter receiver pair. I could have gone with the more expensive hobby quality stuff but to limit the weight and power supply options the toy class parts seemed more suitable. This worked great after being wired up. So I thought. There was an angry mob outside my door when the household realised that it was me who had been disrupting the home WiFi network with my project. Things settled down after I located the manual online and found I was able to shift the transmission frequency outside of the home's WiFi range.



I decided to mount the camera and transmitter inside the remote-control car but in a way without damaging the vehicle. I took it apart and removed the internal shell which made up the windows and roof support structure. By scanning the shell and 3D printing it I could make the required modifications and have the option of returning the car back to its original state if needed. I borrowed a friend's Makerbot Scanner but due to the complexity of the car's shell the 3D models it produced were less than optimal. I found that taking fifty odd photos of the shell and running them through Autodesk's ReMake software produced better results. I went through a few iterations of this before I was happy with the outcome. Only a small amount of editing was then required on the 3D model to smooth it out. Dean helped me with the 3D printing and we got the scale right on the second print. A work college helped me out with the painting options.

To display video from a wireless camera the setup only requires a composite monitor. However, because I wanted to mix the video signals and the computer generated text in the form of a game I needed to incorporate a genlock card. It so happens that I had a genlock card (the Apple Video Overlay Card) just lying around waiting to be used. I had been wondering what to do with this great under-utilised card and now I've found a great use for it. I played around with some timer code in Basic and displayed it as a countdown clock on the screen while having the video feed playing in the background.



Having the timer was great but there was no way of determining when the car had reached its destination. I didn't have anything that would inform the computer of the car's position. I had a few Usborne books from the 80s that showed me how sensors could be wired from slot car sets or train sets or robots to relay back the information to the computer. However, I didn't want to go about running wires everywhere. These days we have plenty of wireless solutions like Bluetooth, RF, ZigBee, WiFi just to name a few. I've had my eye on the ESP8266 WiFi modules and so I figured I could use these for the project and be able to play around with them at the same time. I ordered a handful of them. The cheaper modules I setup as clients since all they need to do is receive a digital signal from a sensor and pass that information onto the server module. I experimented with various sensors (switches, infra-red modules) that would trigger from a passing car. I had issues with using the cheap infra-red sensors during the day time due to the amount of sunlight in the room and their sensing distance wasn't as far reaching as I had hoped. More work needs to be done in this area to get a better solution. The more expensive WIFI module (NodeMCU) brings out many Input/Output pins so it serves as the server which receives the digital location signals and passes them onto the computer via an input card. I used the 4play card for this because I had one on hand and it was easier to setup and use than my other input cards.

The beauty of using the 4play card is that I could now change over from using an analog joystick to using a digital one. The digital joystick is a perfect fit for this type of situation because it matches the four position digital control of the car very closely. The speed difference between processing a digital joystick vs processing an analog one is quite large especially when it's being done in Applesoft Basic.



The last peripheral card that I used for the game was another under-utilised card called the A2MP3 card. It allows you to play, stop and pause mp3s under computer control. Since I'm no musician and to add music to CHECKPOINT would have taken me a considerable amount of time, it was easier for me to sample the theme music and play it back during the game. Since this game is a very customised solution I didn't mind using the A2MP3 card for the game sounds and background music. Using the A2MP3 card was not a trivial procedure. The problem was that I didn't have an A2MP3 card and Vince no longer sells them. I could have borrowed one but there was another option. I had the PCB of the A2MP3 card which I used for my serial Bluetooth concept a few years back. I was missing the part that does the USB file reading and the sound generation but the good thing is that these are still available from electronic stores. The original A2MP3 card came with the FTDI's VMUSIC2 module but I purchased the VMUSIC3 because I already had a firmware programmer for it and it was meant to be plug in replaceable. Plug in replaceable it was not. This was due to Vince using improved firmware in the VMUSIC2 module. I had two options. I could rewrite the firmware for the VMUSIC3 module or I could change the A2MP3 software and do a modification to the A2MP3 base card. I chose the second option since it was the quickest solution and I was quickly running out of time.



I put together the game code, double hi-res title screen, a few theme related props and the OzKFest Powerpoint presentation. This only left me with just one day of system testing. On this day I found out that the noise (electromagnetic interference) generated by the car's motors was enough to cause the video feed to drop out. After giving the video camera and the transmitter its own power source I found that the drop outs had reduced but had not been eliminated completely. This is a classic engineering problem however it's a shame I didn't have enough time to get this sorted before the OzKFest event. There are still many improvements to be done however at least now I can work on them at a less stressful pace.

Thank-you to everyone who helped out with the project. Thank you to the tool builders who make my life easier and thank you to those that take the time to archive and preserve our retro artrfacts. Without these efforts, I would not have been able to do what I do and be able to experience these great extensions of my childhood past. This project is a great example where things are only possible because I have been able to stand on the shoulders of giants. Cheers.

Code and video to follow (one day).

Monday, August 21, 2017

Apple II 4play Joystick Card - Software Resource


I recently noticed that the software which supports the 4play card is scattered about in various locations. I have also been contacted by a few members of the Apple II enthusiast community who have graciously sent me their software conversions. I figured that this might be a good time to consolidate the information. The result of which is the following table. I'll add more software to this list as it becomes available.

Some games are better played when using paddles, some games are better played using an analog joystick and some games are better when played using a digital joystick. It's not my intention to convert every Apple II game to be 4play compliant, just the ones that are easy to convert (the ones that are already digital enabled ie Atari Joyport ones), multiplayer ones because the Apple II was always lacking in this area and also the ones that are the reason why a lot of us got into computing in the first place ie to reproduce that arcade experience at home and not have to spend one's entire pocket money on arcades at the local milk bar. Although I must admit that these days MAME does a great job of fulfilling that need.

Program(s) 4play adaptation/conversion by Apple II card slot Driver 4play port usage Comment Links
KABOOM! Jesse Blue Any Integrated 1, 2, 3 & 4 http://www.ninjaforce.com/html/products_kaboom.html
Star Blazer,
SuperPuckman,
Pac-Man (Atari version)
Lukazi 4 Replaces keyboard code 1 https://docs.google.com/file/d/0B5PVarmqxaOnUUN6OVIteWFqalk
Lode Runner Brutal Deluxe Software Any Replaces joystick code 1 Second web link is for conversion notes and discussion with Antoine. http://www.brutaldeluxe.fr/sourcecode/4play.html
https://docs.google.com/open?id=0B5PVarmqxaOnVXd2OEVtcTl4Q0E
Tapper Michael Sternberg 4 Replaces keyboard code 1 https://docs.google.com/open?id=0B5PVarmqxaOnR00tNXNuM3VFaU0
Boulder Dash,
Boulder Dash II,
Seadragon,
Spy's Demise,
Wavy Navy
Lukazi 4 Replaces "Atari Joyport" code 1 https://docs.google.com/open?id=1U2ZaPhB8TDHceTgKS-jVUeXZNNv4KEq7
Robotron 2084 Nick Westgate Any Integrated 1 & 2 Play as per the original game design ie one joystick for movement and one joystick for shooting. Also supports two analog joysticks. https://drive.google.com/open?id=0B3JBd-TShLlLbldncTJmcHh2NWM
CHECKPOINT Lukazi 4 Integrated 1 & 2 Maybe one day.
Alien Typhoon,
Atarisoft Galaxian,
Starcraft Galaxian
Lukazi 4 Replaces joystick code 1 By popular demand. https://docs.google.com/open?id=1dmvALkPWyiJsb1paglW2eRNIFINMY-VB
Buzzard Bait,
Dino Eggs,
Miner 2049er,
Miner 2049er II,
Plasmania,
Stellar 7
Lukazi 4 Replaces "Atari Joyport" code 1 Some more easy "Atari Joyport" conversions. https://docs.google.com/open?id=1U2ZaPhB8TDHceTgKS-jVUeXZNNv4KEq7
Mario Bros Lukazi 4 Replaces joystick and keyboard code 1 & 2 Two player co-op. https://docs.google.com/open?id=1rsAtvUEg51EA9Y9YQ4mJhPVKqixR-7Gs
Super Taxman 2,
Vindicator
Lukazi 4 Replaces H.A.L. Labs Gizmo code 1 https://docs.google.com/open?id=1ub-yC-yqrjAOmS8MhEK9v5LmkMrSC8Xo