Quickshot Flight Grip

I found this cheap Quickshot Flight Grip aka Quickshot Handlebar aka TecToy Asa. Designated QS-129N, I guess N is for Nintendo. Yes, sadly this is a NES controller, so I can't get instant gratification with playing Afterburner on the C64. Even my only NES machine is a clone that takes in a different kind of connector.

The shape is just irresistible, but it is clear the design is a gimmick and does not work well as a general gamepad.

It's worth noting the idea is not that far from the Playstation 1 controller that became the nearly universal starting point for all subsequent gamepads. It's just the grips are too spreadeagled and the d-pad and buttons are too near the centre. Bonus points for having the B-button as a "shoulder" button here, too.

Unlike the much later Gravis Destroyer Tilt, this Quickshot is NOT a motion-sensor gamepad. And given my experiences with the Tilt, it's perhaps all the better for that.

The size is for smaller hands, but that's not the biggest problem. The d-pad sounds and feels a little lifeless, and sometimes I think the B-button would be better as the principal fire button.

Looking at this from an alternative angle, I can see myself holding it like a boomerang (Batarang?) although then I'm more clearly limited to either the d-pad or the two buttons.

A look inside

Old electronics look often more crude than the outside suggests. The Quickshot is built more like a toy than an object for hardy use.

But it is a clean design. A bunch of screws keeps the outer case together. The circuit board in turn has a couple of tiny screws, after loosing them the whole thing begins to fall apart.

The buttons at front are on a separate board that must be identical to the Atari version of this controller. The NES-relevant stuff is on the central board.

The cable is tied and held fast in a tight curve, and a wide screw helps keep it there. Not sure this is better than having a "stopper" in the cable itself, but it looks firm enough. This also helps me attach whatever cable I need to.

Looking from the other side, the circuit board was quite dirty and I wonder if this would even work without some adjustments.

The main board had the notation "24 Aug 1990" in it, and the tiny board with the d-pad and fire button has the text "Spectravideo 1989".

The Conversion

I felt it should be easy to "downgrade" the gamepad to work in the Atari/Kempston style, as it only requires me to remove the electronics in between and add a different cable.

The first idea was to replace the main circuit board with my own, so I could store the original relatively intact. At the same time I could get to do easy and enjoyable protoboard work.

However, the autofire and select/start buttons require some corresponding physical parts even if they are not meant to work. It is better to keep the original board in place and simply remove the existing connections and replace them with my own.

The only really new thing needed was the cable and 9-pin connector to replace the NES-style connector.

This turned out to be a problem as I didn't have a worse joystick to borrow the cable from!

So, I ordered a lot of four broken joysticks from an auction. I got a possibly recoverable TAC-2 (the most valuable thing in the lot) and another Quickshot brand joystick I might spare. But importantly for my project, a couple of crappy non-brand sticks which I could cannibalize for parts, such as joystick cables.

I de-soldered the ribbon connector and soldered in single wires, which in turn were soldered to the joystick cable ends. The cable had a rubbery stopper which I had to whittle off before I could fit it through the opening in the Flight Grip case.

In the above image I marked the connector wires 1-7.

1: GND
2: Right
3: Left
4: Down
5: Up
6: Fire
7: GND for fire

Testing

I played some games on the emulator through the Arduino adapter box.

Buck Rogers was quite fine as long as I was only turning the ship left and right and firing. When the ship needed to go up and down, it felt far more clumsy.

Buggy Boy worked surprisingly well, as it's also a sort of left-right game. I need to push constantly upwards though and this proved to be a little taxing for the old thumb.

With Stunt Car Racer I experienced first genuine confusion. The acceleration is no longer about pushing up constantly, but has to be managed together with delicate left/right controls. Diagonals are a stretch and I performed considerably poorer than I do these days with a Tac-2.

I also kept missing the 2nd button function, but the question is, what should it do? Replicate fire button? Or replicate Up direction, to give an easier way to accelerate? Hmmm....

Blue Max is one game where I felt a controller like this could be fun. But I'd be lying if I said the Flight Grip delivered here. Blue Max controls are a quirky to begin with and the poor diagonals offered by the controller did not help much.

I also played a couple of games where I expected the controller wouldn't be good at all.

The Great Giana Sisters was not as bad as I expected, but it needs a more accurate controller. It might help to have the second button to be the "Jump" button, so perhaps I'll indeed wire it to "up" and try again.

In Saboteur!, a lot of the movement is left-right only so it was rather good for those portions. However I also have to reach those ladders accurately and this is where the controller failed me and I couldn't bear to play much more.

The controller is a better fit for "3D" games with relatively simple controls. So I wouldn't condemn the Flight Grip concept entirely, it's very clearly not meant to work for all games. If only the buttons and diagonals were more crisp and precise.

Oh, I nearly forgot. I meant to play Afterburner. The game is so atrociously unresponsive it's hard to put the blame on the controller.

I'll get back to this if I solder the 2nd button.

Sinclair QL EPROM

A 28C128 EPROM chip can be connected to the Sinclair QL through the 16K plug-in cartridge ROM port. The memory occupies the space (0xC000-0xFFFF).

I can't guarantee this is the 100% definite way to do it, as I haven't been able to compare this to an existing EPROM cartridge. But it worked for me.

The diagram below shows the basic connections between the QL ROM port pins and the EPROM, with a 7400 chip between.

The 7400 IC should be connected to the 5V and GND too. In addition, two capacitors should be connected to 5V / GND near the two ICs. I had 100nF, which I hope to be ok.

In the above diagram, the NAND gates represent the activity of a 7400 IC for combining the signal of A14, A15 and ROMOEH, connecting the final output to the pin that controls the EPROM enable state. (Low=enable) The data lines should only be active when all of the A14, A15 and ROMOEH signals are high.

I was unsure about the role between -G (gate control) and -E (standby), as the device works when connecting both together. According to the EPROM datasheet the -G is used to set output enable/disable whereas the -E can be held low for device selection.

"Data is available at the outputs after the falling edge of G, assuming that E has been low [...]" makes me think that it's not a big deal timing-wise but it might be clearer if E was low all the time.

I have three QLs, and my first cartridge attempt worked in one of them. This led me to waste time thinking the "fault" could have been something about the differences in the QL models. In this version I had left the A14 and A15 floating, assuming the ROMOEH signal is enough to indicate the 16K area is addressed.

However as it should have been quite obvious from the start, the signals of A14 and A15 need to be combined with the ROMOEH, as the ROMOEH signal is high whenever the whole ROM area (0x0000-0xFFFF) is being read, not just the 16K area.

I used a Toolkit II ROM as a guinea pig. The onboard ROM (version JS) seems to find it "twice" which I hope is normal. The TK2 functions can be activated with the TK2_EXT command and all seemed to be ok.

An EPROM cart like this isn't especially useful these days, as many modern expansions do not work at the same time. Full 64K on-board ROM? Can't use the port. QL-SD? Can't use the port. Tetroid Disk Interface? Can't use the port. So, I'm left with a QL that can have a 16K EPROM and pretty much nothing else.

However this might be the beginnings for making something else, a transfer device etc.

Edit 14.12.2017: I burned 2.20 version of the Toolkit II, which has the FSERVE fileserver. The file server works nicely from the ROM module and is a quite powerful function to have. It alone justifies this little project, maybe I'll write about it later.

The parts list:

-27C128 EPROM + 28 pin socket
-7400 NAND chip, such as SN74LS00, + optional 14 pin socket
-2 x capacitor, I used 100nF

(Ignore the top image which has all kinds of unnecessary things added to it.)

The board

I have been hunting for a good PCB prototype board that would suit the project. It should be obviously with 2.54mm raster and double-sided so that it may have something that works as an edge connector.

I ordered a set from eBay with different sizes. The 50 x 70mm board with 18 x 24 raster is simply a perfect fit for the QL ROM cartridge slot, and there are 16  pads at the edges that just about work for the connector after modifying the board a bit.

The sixth position is cut off, to a depth that includes only the first through-hole. The QL case slot is wide enough for the 50mm width so nothing else needs to be cut.

The prototyping board and the blade for removing through-plating.

The raster holes are plated through, and as the pads are very short, this means the holes would immediately short the top and bottom connector pins. I suppose a variant without through-plating might exist, but it is difficult to tell from the eBay listings.

I rotated a paper/exacto knife blade from both sides of the hole, this way I could get rid of the through-plating from the row nearest to the pads. After all it is a very thin layering. This needs to be done briskly enough so that the chipping away can be felt, yet carefully enough so that the holes don't get ruined.

In the first row I need to be certain there is no contact between the two sides, no dust or thin filaments. This phase adds a bit of tedious handiwork.

The cut could be deeper but then the next row of through-plating should be removed too. One row is just enough for holding the cart in place. The pad width acted as a good guide for the cut width in this prototyping board.

What follows after is likewise tedious connecting of the pads to the chips by wire, for both sides. There shouldn't be too much solder on the pads, so I tinned the wires beforehand and tried to carefully connect them to the pad edges. Even then I made a bit of a mess, and I cut away extra solder with the paper knife.

There's a method for creating paths by solder for this type of board, but it's also slow and results in huge lumps of solder. I used wires for connecting nearly everything.

iCade to Atari 9-pin

iCade arcade style stick on the C64, not unpossible!

Like many retro-heads, I was wowed for a while by the Apple iPad. It seemed that most interesting retro game stuff happened on that platform. But in the end I realized that the device has a major flaw: the touchscreen.  So I went and bought the iCade bluetooth arcade stick. This turned out not to be that great an addition, so it mostly gathered dust in some corner. (Well, mostly I was disappointed with the increasingly degenerating iPad)

When I needed an extra joystick for the C64, I opened the iCade to see what could be done to convert it into a good old-fashioned 9-pin Atari/Kempston joystick. I am aware that this must have been done dozens of times by different people, but I just refused to google it.

I used a breadboard to connect all the ground wires, but this is a bit extravagant.

Funnily, I did not need to solder anything. All the buttons and stick directions are very neatly connected to the tiny circuit board with such headers that easily connect to "jumper/dupont" style wires common in breadboarding. Also, all the ground wires from each button and direction switches are clearly marked black. I guess this all might be part of the intended design and greatly increases the value of the iCade in my eyes.

Example of the iCade header (left) almost connected to a jumper/dupont wire (right). 

Admittedly, what made life easier was that I already owned a couple of very useful pieces. The 9-pin doohickey shown below is a cannibalized COM-port header/connector from a tiny Linux computer I bought from a fleamarket (now destroyed). It's very robust as the connector solder points have been drowned in epoxy. Similarly the 9-pin extender cable is something I have had around for who knows how long. The gender changer was needed in between.

The COM-port thingamajig taken from a linux box, plus a gender changer. The jumper cables don't fit too neatly into the COM-header, though.

It took the longest time to figure out the correct pins, because I was tired. I won't include the diagram now as I'm prone to get it wrong. The Atari 9-pin schematics are lying around the net, but it's not always clear whether it's the jack or the port side. Once the ground has been figured out the directions can be checked one at a time. Wrongly connected pins can mess the C64, especially the CIA chip so take care.

Frankly, the iCade is not ideal for home 8-bit games, as the joystick travels a bit too much compared to, say, TAC-2. The fire buttons are delightful though. For Decathlon-type games, one might even consider connecting the buttons to directions. The neat thing about iCade is that there are numerous buttons, so perhaps in the future I could be motivated to do something a bit more ambitious, like one of the buttons as space bar or other keys.

The backside. Batteries not required!

Arduino boxed

The TV is a Procaster DTV007 with a Video In.

Here are the first results from my previous keyboard rewiring. I've been dying to create some kind of "fake computer" in the 8-bit style, and this is one step towards this goal. I put the keyboard inside a Tactix brand plastic box with adjustable compartments, and connected it to an Arduino.

I don't like the appearance of this plastic all that much, but at least it is quite robust and re-openable.  Cutting the keyboard hole was a bit of a chore, so I cheated and melted rough lines using a soldering iron and then smoothed the edges with a carpet knife.

The Arduino, connected to the keyboard, runs the TVout library. The TVout generates a small resolution video signal, not much better than some LCDs, but in some ways more handy as it only uses 3 pins.

A bit closer up.

The keyboard with a 5x8 matrix uses most of the pins, 5 analog pins are used as digital pins for one matrix direction, whereas pins 2,3,4,5,6,8 & 12 are used for the other direction. (The TVout needs pins 7,9 and 11 for audio. TVout is quite particular about these).

I did not use the available keyboard library because it often seems to mess with whatever else I happen to be doing. So I simply read the 8 input lines each time Arduino sets one of the 5 lines as an INPUT, keeping the others as OUTPUT. The whole setup is largely copied from a ZX Spectrum, as seen from the rough layout below:

The setup does not do anything much as yet, it's bit like a simple typewriter. Let's say a kind of non-mobile Hemingwrite with a ridiculously low memory. The typing feel is pretty good, as the keyboard is of high standard and Arduino does not seem to miss any key presses. I did not make a key repeat, though.

It's not perfect: If I press several keys horizontal and across along the matrix, additional keys covered by the area might be registered. This can fumble rapid operations with SHIFT+key and some other key, depending on their matrix location. I may make a separate switch altogether for the SHIFT.

I'm now thinking of putting a second Arduino inside the box, if the two can be made to communicate. One Arduino could mostly concentrate on handling the keyboard whereas the other would be keeping up the video and some more interesting communications. We'll see...

The Arduino, doing what Arduinos usually do.

Rewiring a keyboard matrix

New year, new old projects. I'll go back to one of my past favorites, a keyboard. I'm rewiring an Apple keyboard into a different electrical matrix, removing all the ICs and stuff. There are some plans for this keyboard but let's focus on rewiring first.

I've lost the picture of the intact keyboard.

This Apple Extended keyboard is a good starting point because it has a switch for each individual key. If nothing else, tearing out all the keys leaves you with a valuable stash of switches.

I was thinking of keeping the arrow keys, but no, too big, too heavy.

After hacking the full keyboard to pieces (with a hacksaw), I'm left with a more limited "8-bit" keyboard. I left out the keypad, arrow keys and function keys, and still I'm left with a fairly heavy lump of keys.

It's possible to tear out individual keys, too.

Then, I cut the electrical connections on the circuit board with a Dremel wheel. I have previously done this with a carpet knife, which produces less dust and noise. But the Dremel saves time. 

Lisää kuvateksti

The above shows it's easy to re-solder the switches, but it is very time consuming. Here I have to hope there are no connections on the other side of the board, but from what I can see it is very unlikely.

I re-wired the switches according to a ZX Spectrum keyboard matrix, using tiny pieces of wires. I'm not going to connect this keyboard to a Spectrum (unless for testing), but it's nice to have some "standard" to work on. 

Halfway there...

Of course, the 5x8 matrix is not sufficient for connecting all the keys, it will have to wait.

I got tired soldering the matrix with small bits of wire, and with the other direction I tried an alternative approach (i.e. an even more horrible kludge). The red wires are longer, and only parts of the wire are exposed where needed. I did this by brutally melting through the plastic coating on the wire, so it's not certain the connections are very good.

Almost there... note that some keys like Space and Enter are further away than they would be on the Speccy.

And there I have it, an old Apple keyboard re-wired into a ZX Spectrum keyboard matrix, although without any lines leading out... yet. So there's still a significant amount of work to do.

Loading JR200 files from Arduino

As a follow-up to Panasonic JR200 tape wave generation some years back, I now had an opportunity to use my specifications for a quick project. Here I have an Arduino UNO work as a "tape" storage for the Panasonic JR200. As the Panasonic JR200 really likes square waves for input, the Arduino digital pins are ideal for the job.

The Arduino produces the waveform over and over from a series of bytes. Using the MLOAD command from the Panasonic end, the computer will load the data next time it loops around. (Resetting the Arduino obviously restarts the "tape")

I spent some time figuring out how to power the Arduino from the Panasonic External Bus, which would be convenient. The first bottom left pin is the Ground. Checking with the multimeter, then, going right, there are five pins between the Ground pin and what appears to be a 5V pin.

Again, I have to say I like the JR200 more and more for the quality of the hardware. I cannot guarantee the below schematic is good for the health of your Panasonic/Arduino/self, but here goes anyway:

Not to scale. The JR200 connectors are as seen at the back of the computer.

I used this setup to load some converted ZX Spectrum loading screens. I noticed the loading can be made somewhat faster, as there's some tolerance in the tape input. At first I used 200 and 400 microsecond square wave lengths to simulate the original speed, but I soon found out that I can use 160 and 320 instead.

So, it might take 26 seconds to practically load a loading screen (4K in two files), that would normally take slightly over 30 seconds. Well, it's a small improvement anyway. At 150ms/300ms, the Panasonic stopped recognizing the signal.

If only I could get rid of the trouble of writing the MLOAD keyword. However, I can at least load BASIC keywords directly into the character display, for example A=USR($1000). So, booting JR200 and using MLOAD would result in a more complex command set, waiting "under the cursor". Machine code can be run from the character display, so a tight package could combine both the necessary keywords to run the code and the code itself.

In glorious flicker-o-vision:

Further ideas:

-Take some signal from the Panasonic to Arduino for triggering the loading. Perhaps the "remote" relay. As the Panasonic gives an audible click when using the MLOAD, there's got to be a relay somewhere.

-The Arduino could just load a short code for high-speed receiving from the joystick port(s).

-Saving files to Arduino. It should be simple enough, but I just can't see the point.


The Arduino sketch:

Copy/Paste to the Arduino editor and upload. Use MLOAD from Panasonic. The example loads just 8 bytes to the character memory. This gives a quick visible effect. For sending your own data, change the contents of the g_data array list. The g_length and g_address are used for setting the start address and the length of the data. The g_offset sets the starting point from which the data is sent, within the g_data array. This only matters if you want to send multiple files.




#include <avr/pgmspace.h>

#define OUTPIN 9
#define MSHORT 200 //160
#define MLONG 400 //320
#define MLONGEST 800 //640

// Panaduino
// Uses Arduino pins to send a tape signal to Panasonic JR-200
// 15.7.2014 Dr. TerrorZ

unsigned int g_level,g_chek,g_blok,g_length,g_address,g_offset;

// The data.
// PROGMEM is necessary for anything longer.
// The actual g_length, g_address and g_offset are set in loop()
// 

prog_uchar g_data[] PROGMEM={1,2,4,8,16,32,64,128};

void switchlevel()
{
  if(g_level==LOW){g_level=HIGH;return;}
  g_level=LOW;
}

void send0_600()
{
  digitalWrite(OUTPIN,LOW);
  delayMicroseconds(MSHORT);
  digitalWrite(OUTPIN,HIGH);
  delayMicroseconds(MSHORT); 
  digitalWrite(OUTPIN,LOW);
  delayMicroseconds(MSHORT);
  digitalWrite(OUTPIN,HIGH);
  delayMicroseconds(MSHORT); 
  digitalWrite(OUTPIN,LOW);
  delayMicroseconds(MSHORT);
  digitalWrite(OUTPIN,HIGH);
  delayMicroseconds(MSHORT);
  digitalWrite(OUTPIN,LOW);
  delayMicroseconds(MSHORT);
  digitalWrite(OUTPIN,HIGH);
  delayMicroseconds(MSHORT);
  g_level=HIGH;
}

void send1_600()
{
  digitalWrite(OUTPIN,LOW);
  delayMicroseconds(MLONG);
  digitalWrite(OUTPIN,HIGH);
  delayMicroseconds(MLONG);
  digitalWrite(OUTPIN,LOW);
  delayMicroseconds(MLONG);
  digitalWrite(OUTPIN,HIGH);
  delayMicroseconds(MLONG);
  g_level=HIGH;  
}

void send0()
{
  digitalWrite(OUTPIN,g_level);
  delayMicroseconds(MSHORT);
  switchlevel();
  digitalWrite(OUTPIN,g_level);
  delayMicroseconds(MSHORT);
  switchlevel();
}

void send1()
{
  digitalWrite(OUTPIN,g_level);
  delayMicroseconds(MLONG);
  switchlevel();  
}

void sendlong1()
{
  digitalWrite(OUTPIN,g_level);
  delayMicroseconds(MLONGEST);
  switchlevel();  
}


void filler600(int a)
{
  int i;
  for(i=1;i<=a;i++){
    send1_600();
  }
}

void filler(int a)
{
  int i;
  for(i=1;i<=a;i++){
    send1();
  }
}

void sendbyte(int a)
{
  int b,c;
  send1();
  send1();
  send1();
  send0();
  b=1;c=a&b;
  if(c!=0){send1();}else{send0();}
  b=2;c=a&b;
  if(c!=0){send1();}else{send0();}
  b=4;c=a&b;
  if(c!=0){send1();}else{send0();}
  b=8;c=a&b;
  if(c!=0){send1();}else{send0();}
  b=16;c=a&b;
  if(c!=0){send1();}else{send0();}
  b=32;c=a&b;
  if(c!=0){send1();}else{send0();}
  b=64;c=a&b;
  if(c!=0){send1();}else{send0();}
  b=128;c=a&b;
  if(c!=0){send1();}else{send0();}  
  g_chek=g_chek+a;
  if(g_chek>255){g_chek=g_chek-256;}
}

void sendbyte600(int a)
{
  int b,c;
  send1_600();
  send1_600();
  send1_600();
  send0_600();
  b=1;c=a&b;
  if(c!=0){send1_600();}else{send0_600();}
  b=2;c=a&b;
  if(c!=0){send1_600();}else{send0_600();}
  b=4;c=a&b;
  if(c!=0){send1_600();}else{send0_600();}
  b=8;c=a&b;
  if(c!=0){send1_600();}else{send0_600();}
  b=16;c=a&b;
  if(c!=0){send1_600();}else{send0_600();}
  b=32;c=a&b;
  if(c!=0){send1_600();}else{send0_600();}
  b=64;c=a&b;
  if(c!=0){send1_600();}else{send0_600();}
  b=128;c=a&b;
  if(c!=0){send1_600();}else{send0_600();}  
  g_chek=g_chek+a;
  if(g_chek>255){g_chek=g_chek-256;}
}


void header(int id)
{  

  //in 600 baud format

  g_chek=0;
  sendbyte600(2);
  sendbyte600(42);
  sendbyte600(0);//block#0
  sendbyte600(26);//fixed length of data for block #0
  sendbyte600(255);
  sendbyte600(255);
  sendbyte600('P');//filename 16
  sendbyte600('D');
  sendbyte600(48+id);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(0);
  sendbyte600(1);//binary1,basic 0
  sendbyte600(0);//baud rate for the rest. 0=2400, 1=600
  sendbyte600(255);
  sendbyte600(255);
  sendbyte600(255);
  sendbyte600(255);
  sendbyte600(255);
  sendbyte600(255);
  sendbyte600(255);
  sendbyte600(255);  
  sendbyte600(g_chek);//checksum
}

void datablock(int len)
{
  unsigned int i,adhi,adlo,lbytes;
  unsigned int bb;
  unsigned char cc;
  lbytes=len;
  if(len==0){lbytes=256;}
  g_chek=0;//reset checksum
  adhi=g_address/256;
  adlo=g_address-(adhi*256);
  sendbyte(2);
  sendbyte(42);
  sendbyte(g_blok);//block nro
  sendbyte(len);//length 0=256
  sendbyte(adhi);//hi addy
  sendbyte(adlo);//lo addy
  for(i=0;i<=lbytes-1;i++){
    bb=0;
    cc=pgm_read_byte_near(g_data+(g_blok-1)*256+i+g_offset);;
    bb=int(cc);
    sendbyte(bb);
  }
  g_address=g_address+lbytes;
  sendbyte(g_chek); 
}

void lead_out()
{
  int adhi,adlo;
  adhi=g_address/256;
  adlo=g_address-(adhi*256);
  sendbyte(2);
  sendbyte(42);
  sendbyte(255);
  sendbyte(255);
  sendbyte(adhi);//hi addy
  sendbyte(adlo);//lo addy
}

void send_tape(int tapeno)
{
  int i,dblocks;
  int lef;
  
  dblocks=g_length/256;
  
  g_level=LOW;
  g_chek=0;  
  g_blok=1;
  
  //600 baud portion
  filler600(850);
  header(tapeno);
  filler600(51);
  
  //2400 baud portion
  for(i=0;i<=dblocks;i++){
   if(i==dblocks){
     lef=g_length-dblocks*256;
       if(lef==0){datablock(1);}
       if(lef>0){datablock(g_length-dblocks*256);}
     }
   if(i<dblocks){datablock(0);filler(196);}
   g_blok++;
  }
  
  sendlong1();
  filler(188);
  lead_out();
  sendbyte(255);
  filler(150); 
}

void setup()
{
  pinMode(OUTPIN,OUTPUT);
  digitalWrite(9,LOW);
  pinMode(13,OUTPUT);
  digitalWrite(13,LOW);
}

void loop()
{ 
  g_length=8;
  g_address=0xd000;
  g_offset=0x0000;
  send_tape(1);
  
  pinMode(OUTPIN,OUTPUT);
  digitalWrite(9,LOW);
  delay(100);
  
  //for multiple MLOADs, use separate tape loads.
  //delay(1500);
  //g_length=0x0800;
  //g_address=0xc100;
  //g_offset=0x0800;
  //send_tape(2);
}