C64/Amiga « modelrail.otenko

22Jun/160

Serial Train Controller (C64+Arduino)

I'd previously attempted to use the parallel port for train control but have now switched to the Serial port for communications. I've also slapped an Arduino in between the layout and the controlling (Terminal) device. The Arduino will be programmed to understand data coming in from the Serial port, which can be fed from any device which is capable of outputting an RS-232 signal. For the example below, I'll be doing this from a Commodore 64. See this article to learn how to build a Serial Port for your C64.

Designing a communication language

Since we'll be using the RS-232 standard, we're able to define a language that any Terminal can speak to control the Arduino. This will be based on ASCII for command verbs and then raw byte data where targets and values are required. For instance, we could set throttle number 1 to 150 or point number 4 to left. Without being too tricky, 3 bytes is adequate to communicate these commands: C|T|V. If we wanted the data messages to be 'human readable' (so you can print them straight out to a file or other serial line), then we should send through 7 bytes C|TTT|VVV, where the target and value are padded out with zeroes. Fortunately, we only need these two to be 8-bit values, which is the definition of a byte. We'll simply have to convert them to ASCII if we ever want to print or display them.

Next, we'll need a command separator. I've chosen the exclamation mark '!'. Hence, when sending commands, our messages will be 4 bytes long. The recipients will need to wait data, ensure there is at least a full 4-byte message with a terminator and then start processing.

Important Note: As is described down below, I found out the hard way that not all text is equal. I've naively mentioned 'ASCII' two paragraphs above and jumped straight onto the C64, compiling strings and sending them down the wire. For some reason, although I full-well knew that I was coding in PETSCII, I neglected to think that it would actually send it down the line! Long-story-short, when the C64 sends a capital A, it actually sends a character that does not map to ASCII. Also, when it sends a lower-case A, it is actually seen in ASCII as an upper-case A!

Moral of the story? Make sure you understand what character set each device is transmitting and receiving!

Talking back to the Terminal

Although everything written above indicates that most of the communication will be one-directional; this won't always be the case! Some of the commands in the table below will actually be asking for data from the layout. This will be in the form of sensor blocks, where optical or occupation sensors will exist on the layout and be wired to binary input data. The Arduino will be hooked up to shift registers which, when daisy-chained, will be capable of 'watching' up to 64 inputs.

To get this data back to the terminal, we'll send through a message of 10 bytes. This will start with the letter S and be followed by 8 bytes of binary data indicating the state of all connected sensors. Finally a '\0' will be appended to indicate the end of the message. The Arduino wont expect a response to this; if the Terminal has failed to receive, then it can simply request the data again.

The Command Table

Now that we have our expectation of 3 data bytes and one terminator per message, we can start to define all of the commands expect to send.

Command	Target	Data
T Set Throttle	1 or 2 The Arduino will have two separate PWM throttles.	0 to 255 The throttles will supply 12v DC PWM. The wave-cycle will be dependent on the value from 0-255. This maps to 0-12v. Hence 128 should be roughly ~6v.
D Set Direction	1 or 2 Each throttle has it's own direction.	F or R Forward or Reverse.
P Toggle Point	1 to 8 8 separate points will be connected.	L or R We'll use ASCII here to make life easier. Left or Right can be specified.
S Read Sensors	0 We don't need to specify a block... we'll get the whole 8 bytes back regardless.	0 No value required here. We'll send a zero for padding.

Command

Target

Data

Set Throttle

1 or 2

The Arduino will have two separate PWM throttles.

0 to 255

The throttles will supply 12v DC PWM. The wave-cycle will be dependent on the value from 0-255. This maps to 0-12v. Hence 128 should be roughly ~6v.

Set Direction

1 or 2

Each throttle has it's own direction.

F or R

Forward or Reverse.

Toggle Point

1 to 8

8 separate points will be connected.

L or R

We'll use ASCII here to make life easier. Left or Right can be specified.

Read Sensors

We don't need to specify a block... we'll get the whole 8 bytes back regardless.

No value required here. We'll send a zero for padding.

Code for the Arduino

The Arduino will need to keep an eye on the serial port and act on commands when they appear on the channel. Data from the serial port will come in as singular bytes, so they'll need to be written into a buffer and processed once a whole message is found. In case the Arduino struggles, it'll need to be able to understand what a whole message is and discard anything that looks incomplete.

I'll skip the bits on PWM throttles, reading sensors and LED Matrices here... I'll describe all that in another article. Currently you can find individual articles on each of these topics on this site if you need the information straight away.

#include <SoftwareSerial.h>
SoftwareSerial mySerial(8,9); // RX, TX

void setup() {
	// set the data rate for the SoftwareSerial port
	mySerial.begin(2400);
}

...

void processCommand() {
	int x = 0;
	switch (serial_buff[0])	{
		case 'T':
			setThrottle(serial_buff[1], serial_buff[2]);
			break;
		case 'D':
			changeDir(serial_buff[1], serial_buff[2]);
			break;
		case 'P':
			//adjust point
			break;	
		case 'S':
			//read sensors and return the data.
			break;
						
	}
	
	for (int x = 0; x < SERIAL_MAX; x++) serial_buff[x] = '\0';
	last_pos = 0;
}

...

void loop() {
	//if there's data and we've not read the end of the current message.
	if (mySerial.available() && (last_pos == 0 || last_char != '!')) {
		last_char = mySerial.read();
		serial_buff[last_pos] = last_char;
		last_pos++;
		if (last_pos > SERIAL_MAX) {
			//then we need to do something drastic
		}
		if (last_char == '!') processCommand();
	}
}

The snippet above checks if there's data and if we don't already have data. If the buffer is empty, then it'll read a character into it. If that character happens to be '\0' then it'll prevent further reading and process the message.

Controlling with a Commodore 64

cc65 has all the libraries we need to get the serial interface up and running; see more on that here. We'll use a text-based interface and control everything with the keyboard. At a later date I'll write a GEOS-based GUI.

I attempted to use the Tiny Graphics Interface libraries that cc65 provides. Unfortunately, that would've also meant writing a text renderer or graphical font library as the basic 'text out' for TGI isn't implemented on the C64. Staying with text-mode was to be easier and PETSCII has enough cool symbols to draw throttles and the like.

The screen displays the throttle, just one for now, and the direction. It also provides a clock and a schedule. The user can add and edit items in the schedule and, when in run mode, these will be executed accordingly.

void sendCommand(unsigned char c, unsigned char t, unsigned char v) {
	ser_put(c);
	ser_put(t);
	ser_put(v);
	ser_put(33);
}

...

void main() {
	...
	sendCommand('d', 1, current_direction);
	sendCommand('t', 1, current_throttle);
	...
}

I've left out most of the guff ... I'll include the full source soon. For the meantime, you'll see that I've put individual characters to the serial channel for reading at the Ardunio end. Specifically they are lower-case! You'll also note that I write 33 instead of the literal character !. The reason is, of course, that the exclamation mark in PETSCII is not the same as ASCII.

What's Next?

This works. The train happily moves back and forth using the signals sent from the C64! It's overly boring though and based on the clock. I want sensors read back to be able to trigger events... so I'll hook up the multiplexing and post again shortly.

No Comments

19Jun/1620

Commodore 64: Serial Interface to Arduino

So, in my previous post, I was heading towards building an archaic circuit to control trains with the User Port. This would've worked, had I spent a lot more time and built a very complex circuit. Instead I've now chosen a new path... let's hook the C64 up to an Arduino and do most of the work there. The C64 can be the display and input/output for controlling the trains.

Interfacing both components

The C64 User Port has both a 'parallel port' with 8 i/o pins and a serial port. I initially wanted to use the parallel pins, but came to the conclusion that I'd have to write my own language on both sides and deal with the data transfer timings and clock synchronisation. Instead, it'll be easier to use industry-standard RS-232!

I suppose this is a bit of a cop-out. I wanted to build something that was dated to the level of technology that existed back when these machines were in their prime... unfortunately my electronic knowledge isn't up to scratch... so getting to a variable 12v output wasn't overly easy. It also would not have been PWM. Due to all this, including the Arduino into the mix isn't such a bad idea. Plus, everyone I'd asked for help told me to do this... even sending me links to my own blog posts :)

DTE vs. DCE

Serial plugs have a single channel, with each end having one transmit (TX) and one receive (RX) pin. Each end will send data down the cable via the TX pin and expect to receive data on the RX pin. Standard serial cables are 'straight through', meaning that the TX pin is connected to the TX pin and likewise with RX. Doesn't quite make sense, does it? How are two separate devices meant to eachother if they are both transmitting down the same singular TX wire and hearing silence on the RX?

This all becomes clear once you realise that devices fit into two categories: DTE (data terminal equipment) and DCE (data circuit-terminating equipment, also known as data communication equipment.) In the end, these two devices boil down to one being the master (the DTE) and one being the slave (the DCE.)

Of course, you can purchase 'cross-over' cables for serial connections. These are known as null-modem cables and allow you to hook two DTEs together. Say, for example, you want to transfer a file from your PC to your Amiga, or somesuch!

In my previous serial project, when I connected the IBM receipt printer to the Arduino, I needed the Arduino to be the master, and so I hacked around until I had correctly configured it as a DTE. This time around we want the Arduino to be the DCE. Due to this, be careful to follow the pinouts and wiring from the serial port to the MAX232 in the circuits below!

Note: For further reading/wiring on RS-232, there's a good article at avr Programmers and another at Advantech.

C64 Serial Port

The User Port on the C64 also has serial connections. These are TTL and so need to be brought up to the RS-232 5v standard. The MAX232 IC will do this for us quite easily. We'll also use one at the other end for the Arduino.

UPDATED (2024): The CTS and RTS wires were incorrectly ordered on the original diagram. The following diagram is now correct, but I've decided to leave the comments at the bottom of this article which state otherwise.

The circuit is derived from 8bitfiles.net. This circuit was also correct in that the pins are wired up as DTE. This means that you could use it, as-is, to also hook to a modem or any other DCE device.

The MAX232 needs few extra components. Fortunately, these extra components are identical on both ends, so buy everything in duplicate! The capacitors are all 1.0uf electrolytic. I used 1k resisters on the LEDs so as not to draw too much current from the User Port.

Arduino Serial Port

This is nearly the same circuit as the C64 end. The funniest thing happened here... if you google enough 'arduino max232' you'll just loop back around to my post, from ages ago on interfacing an IBM printer to the Arduino. Just make sure you don't use that circuit! It's DTE, we need DCE as per below! I've left out the RTS/CTS as I don't intend on using any form of handshaking in this project. It's still in the circuit above for the C64 so that you can use the port for other purposes.

As per usual, make sure you DO NOT apply 5v in the wrong direction... I did and it ruined a few caps and possibly the IC. Garbage then came through the serial port. If this ever happens, then throw out the components and start again; you'll never be able to trust them.

Also make sure that you use the 5v pin on the Arduino. AREF is NOT a valid voltage source.

Hooking it all together

Build both circuits above and give one a male and the other a female db-9 connector. The DCE device usually gets the female, so put this on the Arduino-side!

If you want to roll your own cable, then grab some grey IDC and two crimp-style plugs. Just make sure that you have pin 1 matched to pin 1. If you're splitting the cable, then paint a wire (or use a marker) to ensure that you get the orientation correct. It's really easy to confuse pin 1.

From above, you can see the pin numbering. I slid the second port all the way to the end, prior to crimping, to ensure that the numbers matched up. Using the red '#1 wire' on the cable worked wonders too.

Testing with Strike Terminal 2013 Final

Download Strike Term 2013 Final from here and then get it to your C64. I copied the D64 to my SD2IEC and loaded it up. Hit M and select User port. Hit b and switch it to 1200 Baud (or other baud, depending on what you've configured in the Arduino.)

Once ready, hit f5 and then hit enter on the default server. This'll start sending modem AT commands down the serial and they should start showing up at the other end. Either open the Arduino Serial Monitor... or edit the code to display it. I bought some 8x8 LED Matrices to render the data coming in.

There were no real caveats here... everything just worked! Press f3 to get to the terminal. Hit commodore+e for local echo and then commodore+i to 'send id'. You should now be able to type freely... everything will be sent down the wire.

At that point I only had one matrix... so the last char typed was displayed.

Writing C code to use the Serial Port

Nanoflite has written a 2400 baud User Port Serial Driver for cc65. I originally tried to use this at 1200 baud, as that's what I'd been using everywhere and heard it was the max the User Port was capable of. It turns out that this driver only supports 2400 baud! Download it and put the source somewhere.

Switch to the driver directory and compile it:

cl65 -t c64 --module -o c64-up2400.ser c64-up2400.s

Copy this to the folder that has your source file it. I slightly modified the example.

#include <stdlib.h>
#include <stdio.h>
#include <conio.h>
#include <serial.h>
#define DRIVERNAME  "c64-up2400.ser"

static const struct ser_params serialParams = {
    SER_BAUD_2400,      /* Baudrate */
    SER_BITS_8,         /* Number of data bits */
    SER_STOP_1,         /* Number of stop bits */
    SER_PAR_NONE,       /* Parity setting */
    SER_HS_NONE         /* Type of handshake to use */
};

int main (void)
{
  int xx;
  
  clrscr();
  puts("C64 serial ...");

  // Load driver
  ser_load_driver(DRIVERNAME);

  // Open port
  ser_open(&serialParams);

  // Enable serial
  ser_ioctl(1, NULL);

  for (xx = 0; xx < 10; xx++) {
	ser_put('C'); 
	ser_put('6'); 
	ser_put('4');
	ser_put('.');
	ser_put('.');
	ser_put('.');
  }
 
  return EXIT_SUCCESS;
}

Compile this:

cl65 -t c64 -O -o trainctl2 trainctl2.c

I then put it on the SD2IEC and loaded it via LOAD "0:TRAINCTL2",8 followed by a RUN.

Shit... worked... this is great! Next it's time to put a PWM throttle onto the Arduino and control it from the Commodore... I'll tinker with graphical programming in C also.

20 Comments

7Jun/160

Commodore 64: Datasette Maintenance

So, Double Dragon had issues loading on a Tape Drive I'd acquired. It had come in a mouldy box, so I had a hunch that the drive itself would need a thorough clean and alignment.

There are multiple alignment tools, downloadable as disk images or PRG files. I could copy these onto my SD2IEC, but there was an issue: the SD2IEC gained power from the Datasette port which was now in use by the Datasette drive itself!

Powering the SD2IEC from the Datasette Cable

Fortunately, the Datasette plug has a screw that makes accessing the internal pins very easy. I opened it up, taking note of the cracked, flimsy plastic, and inspected the contents.

The green wire, pin 2, is the +5v that we're after. Bare back some plastic on the wire so we can solder to it. I found a male+female standard round DC power socket to use. Make sure the female is on the 'power' side, otherwise you'll have a potential for shorts if there is exposed bare metal with current flowing through it. Of course, the outer metal is ground, but still better to be safer than sorry.

From here I soldered on the plug and grinded out some plastic from where the main cable feeds in. This allowed the plug to hang out the end. Not the cleanest job, but it worked quite well. I sorted wanted to feed it out the side where the ground wire is... but I hadn't left enough length.

Next, on the SD2IEC end, bare some wire also. Grab the plug and solder it on, then use some form of insulator to tidy it all up. Nothing a little duct-tape can't fix.

Everything was plugged in and good to go!

Cleaning the head

Everyone recommends alcohol (isopropyl) wipes for this. The wipes have the benefit of leaving little residue and drying cleanly. You'll find that KFC wipes are also usable.

Take the swab out of the packet and wipe the heads, specifically the central metal one. I didn't actually know which way to wipe, or how much pressure to apply. So just be gentle and attempt to remove any visible dirt. Don't put a tape back in until everything is try.

Aliging the head

There are a few options here. Download Cassette Azimuth, also known as 'Recorder Justage', and Minimal Head Align. Both do the same thing, the former is more complex.

I copied them both onto the SD2IEC and then loaded them via the file browser. Cassette Azimuth is easy to work with. Load it up and then hit play on your tape. If nothing is happening then you'll need to start adjusting the player already. If you see data, and it's erratic, then you'll also need to adjust. The goal is to have straight vertical lines.

To actually do the adjusting, there is a tiny screw-hole above the rewind button that a small jeweller's screw driver will fit through. When the tape drive is playing, the hole lines up with the head adjustment screw. Turn this screw all the way clockwise (not too much pressure!) and then turn back in small increments as required. Pause between turns to let the screen update with the new readings.

You can hit F1 to get the guide-lines for the data. I couldn't work out if the data lines were meant to draw over the top, or in between, or where... but at least I got them vertical!

Here's the same process with Minimal Head Align. The app is much more raw; it starts off with a screen full of garbage which starts refreshing once you start feeding it data from the tape drive.

Back to Double Dragon

I had assumed that all the loading issues were from a dirty/misaligned head... so I thought I'd try the game again now that the tape was producing cleaner, more vertical lines on the test programs. I didn't have much faith... but it worked! It took just as long as last time, but this time I got to the first level!

The graphics are intense... hah. Controlling the character was hard at the start... then I realised it was because my controller probably hadn't been used in a decade. I'd found a sega mastersystem controller at a second-hand shop over the weekend. Works perfectly.

So as the game was loading, it got to the point right before the title and asked me to reset the counter to 0. Turns out this is so that, when you die, you know where to rewind the tape to.

From there you rewind to zero, press play... wait for the load and then have another go. I might try source the game on floppies to see if the extra data capacity allowed for a different version. Hmm... then again if this review is anything to go by, then there's no hope.

No Comments

6Jun/167

Amiga 1200: Installing AmigaOS 3.9

After having Amiga OS 3.1 on the 1200 for a while, I'd decided it was time to upgrade to Amiga OS 3.9. I had instantly realised there was a problem with this; the installation media is on a CD! There was no way I was going digging for an accelerator card with SCSI, or a PCMCIA CD Drive, so I resorted to emulation to get the OS installed. Therefore, henceforth are the steps required to build a compactflash card with a real OS for use on real hardware. Godspeed.

Please note, a lot of this was gleamed from watching How to add a 8 GB Compact Flash hard drive to your Amiga 1200 (works with 4 GB too) and I want to thank Alex Rosato for providing this video. Please watch it if you have any issues with the steps here.

I also need to thank GothicKane for his video Upgrading Workbench 3.1 to Amiga OS 3.9. Both videos combined were required to get my A1200 up to AmigaOS 3.9.

Finally, the requirements are as follows: An Amiga 1200 with Kickstart 3.1, an 8gb CF Card + adapter and an accelerator card or memory expansion of at least 4mb. The base 2mb in the Amiga 1200 is not enough to run Amiga OS 3.9 successfully!

Choosing a CF Card

There's no real requirement here. Most posts will indicate that your card needs to be no bigger than 4gig. This tutorial will expect that your card is 8gig. I bought the smallest card available from a local camera shop (seems to be the only retail shops left with stock!) and 8gig was the minimum. I therefore had to go to extra lengths to get the partitions created. But it's now working perfectly.

Next you'll need a CF Card Reader for your ('non-amiga') computer. I've got a crappy USB all-in-one and it works fine.

Partitions

Off-the-shelf CF cards will come with FAT partitions on them. On Windows 10, drop to command prompt (Start, cmd) and then type diskpart. You'll get UAC prompt, accept it. You'll now need to be VERY CAREFUL. Type list disk and work out the number of your CF Card.

Microsoft DiskPart version 10.0.10586

Copyright (C) 1999-2013 Microsoft Corporation.
On computer: WHITEBOARD-PC

DISKPART> list disk

  Disk ###  Status         Size     Free     Dyn  Gpt
  --------  -------------  -------  -------  ---  ---
  Disk 0    Online          465 GB      0 B
  Disk 1    Online         1863 GB      0 B
  Disk 2    Online         1863 GB   879 GB
  Disk 3    No Media           0 B      0 B
  Disk 4    Online         7847 MB      0 B
  Disk 5    No Media           0 B      0 B
  Disk 6    No Media           0 B      0 B

DISKPART>

As you can see, the all-in-one reader provides too many disks to choose from. Either way, I know I have an 8gig card in the slot, so it's Disk 4 that we're after. Therefore, type select disk 4. From here we need to view the partitions, so type list partition.

DISKPART> select disk 1

Disk 1 is now the selected disk.

DISKPART> list partition

  Partition ###  Type              Size     Offset
  -------------  ----------------  -------  -------
  Partition 1    Primary           7847 MB      0 B

DISKPART>

Once you're sure that you've got the right disk, and that you see the correct list of partitions to remove, you can either delete them one-by-one or use the command clean. I actually take objection to Microsoft indicating that 'clean' should clear all partitions. It sounds quite innocent when, in fact, it is obliterating all your data!

Either way, the goal is to end up with zero partitions on your CF card.

Installing and Configuring WinUAE

Our emulator-of-choice for the Amiga is WinUAE. Download it from here. Once installed, you'll need to always open it via Run As Administrator. WinUAE will need higher system privileges to access the low-level area of your CF Card, so don't forget to always run it in this manner. If you don't, then chances are you'll see "Access Denied" next to the CF card in the list further on.

Here's the fun part... to get WinUAE booted, you'll need the following items:

Kickstart ROM 3.1
Workbench 3.1 Disks (ADF)
AmigaOS 3.9 CD

I.. won't tell you how to get them... but it's not hard... any of those terms, with the relevant verbs appended, when typed into google, should get you the binary 1s and 0s that you seek.

Next are some supporting files to allow greater-than-4gb disks to be useful. Create a folder somewhere on your disk and call it work. Download and extract (you can use 7-zip for this) the following to this directory:

Once you have the required loot then you can configure the rest of WinUAE to get a bootable emulator.

1. Quickstart: Select the A1200

2. ROM: Load your Kickstart ROM

3. Configure the FastRAM to 8mb

4. Load the first 4 floppies

5. Add Hard Drive (from CD/HD Panel)

6. Add Diretory Or Archive (from CD/HD Panel)

7. Select ISO Image and Add SCSI/IDE CD Drive

8. Save your configuration

9. Hit Start

Creating Amiga Partitions

Start the emulator with its new configuration... patience will be required throughout the rest of this process. You should end up at the workbench desktop with a crap-tonne of floppies mounted. Firsly we'll drill into the work folder, where we have our after-market goodies, and partition the new disk.

At this point, I'm going to assume you extracted the goodies into this folder, if you haven't, then go do so now! Browse to work and open the HDInstTools drawer (that's what they're called on Workbench) and then the HDInstTools application. There should be one item listed here: the CF Disk as 0 0 0 with manufacturer of UAE-IDE.

Select this disk, make sure it's highlighted, and then press the File System button. At this stage there shouldn't be any filesystems listed, so choose Add... and select: work:Smartfilesystem/AmigaOS3.x/L/SmartFilesystem. Once selected, change the DOSType to SFS\0 (PRESSING ENTER AFTER CHANGING THE VALUE!.) Now press the Use button and you'll return to the FileSystem list. Press Use again to return to the main HDInstTools menu.

From here, since we now have a new filesystem declared, we can create partitions under it. Select Partition drive... and then hit Add Partition. A partition the full size of the disk will be created, but we don't want this. So hit Edit partition... so we can configure it further.

Drag the size slider to somewhere below 4gig. I would actually recommend below 2gig. Here I chose 1gig for this first partition. Set the File System to Custom and then manually type in SFS\0 for the DOSType. Press ENTER after typing in the new code whilst the text cursor is still in the text field! The cursor will move to the next field when enter is pressed. This way you'll be sure that the value has been applied. Next, change MaxTransfer to 0x001FE00 and Buffers to 100. Hit enter after entering each value! Then press the Use button to confirm changes to your first partition.

At this point, add as many other partitions as you want using the exact same method as above. They can be any size after this, but make sure that, if you're ever going to boot on an older Kickstart (pre v3.1) or older OS that you keep them at sane values. 2gig is a good theoretical maximum. There's also no harm in multiple 2gig drives for games, utilities, videos, mods, mp3s, downloads, etc...

Once you've got your partitions configured, hit Use and then Save changes to drive. At this point you'll be told that you need to restart. Hit F12 to get to WinUAE's configuration and save your settings. Finally, press the restart button in the bottom-left of the WinUAE control panel.

If all goes well, you'll be back at workbench with a DH0:NDOS on the desktop also. If this isn't visible then you'll need to go back to the start and open HDInstTool and see what configuration has stuck and what hasn't. Work out the gaps and run through the process again.

If you can see DH0:NDOS, then it's time to format it. Open up the Workbench3.1 disk, browse to System and then open the Shell. Browse to the smartfilesystem folder (cd work:SmartFileSystem) and then format the disk with the following command: sfsformat drive DH0: name OS. You can call the partition anything you want here.

If OS then appears on your desktop then you're set to install your operating system!

Installing Workbench 3.1

This is a pretty straight-forward install. You can save a lot of time by making sure the first 4 disks are already in the drives. You'll want wbench,install,extras and locale in first. Once ready, go to the Install disk and run the English installer.

A lot of the time you'll be hitting Proceed as we'll be using a lot of the default settings. Choose Intermediate Install and then go with the defaults. Make sure that the location is correct. You can see that my default location wasn't correct and that I had to select the proper OS: drive.

Once that's all out of the way, the installation will proceed. Let it do its thing until it asks for the next disk. This will be the Fonts disk. It'll want the Storage disk after this, so put both in to the df2 and df3 slots. Hit F12 to get to the WinUAE Configuration window and then swap the disks in.

Let it chug along further until you get the message to restart. Hit F12, eject all of the floppies and then reboot the emulator.

Congratulations, Workbench 3.1 is installed.

Other patches

Firstly, add the latest version of Installer to your new WB. This will allow your to install applications that require the newest version. Drag the executable to OS:C/.

NSD is the 'new style devices' driver. Install this by double-clicking on it.

Now it's time for the next version of WB.

Workbench 3.9

And finally... The latest release for the A1200. This is also very simple. Just make sure you have the 8mb of FastRAM configured and the ISO in the drive. Firstly, we need to set up the CD Drive. So head into WinUAE Configuration and then to the CD/HD tab. Here you need to Add SCSI/IDE CD Drive. Choose the defaults and hit Add CD Drive. Load the ISO into the slot at the bottom of the window. Also make sure that CDFS automount is enabled!

Reboot WinUAE and you'll have a CD on your desktop. Find and run the installer.

And now... the installation. Very straight-forward... hit Proceed in most circumstances. Just make sure you choose a OS3.9 full installation over OS3.0 or empty HD. Also make sure you get the target disk correct!

Restart and you're there! Browse to OS:Prefs and double-click on ScreeMode to change the screen resolution and color depth.

Boing Bags

These are service packs for the Amiga. Download Boing Bags 1-4 here. Install them in order, started from 1. Make sure you install the ROM update from BB2.

Extra features

The OS3.9 CD has a few goodies on it. Don't forget to browse it and copy anything you might want onto your HDD. It gets painful down the track if you have safely secured your CD Card into your A1200 and then have to fight floppy disks to transfer data across.

I'll post again on OS3.9 when I work out what you can do with it. Learning starts now...

Filed under: C64/Amiga, Retro 7 Comments

3Jun/160

Commodore 64: Tape Drives

This was really a lesson in jumping in the deep-end. I'd bought Double Dragon for the C64 recently on eBay, somewhat blindly, and found out that it was on datasette. It had been relegated to museum shelf until I happened across a cheap tape drive. Below is the story of learning how these things work.

The Datasette drive arrives

The seller had mentioned 'original box' and 'complete'. Indeed it was. I take it, though, that the box had been in the back of the shed for quite some time. The manual pages were mould-glued shut and the box was probably releasing spores every time I touched it. Due to this, I took photos for historical-sake and then destroyed the evidence; keeping only the actual drive.

The first game: Double Dragon

Double Dragon (for C64), released by Melbourne House (more information here), is a side-scrolling beat-em-up. The name of the company is confusing, as it sounds like it might be Australian, but was actually started in London. There is/was an Australian branch though, but it was known as Beam Software.

I'd played this game with my brother decades ago on the 286/386. Actually, I think nearly every Australian kid who grew up in the 80s/90s would've played this on a platform somewhere... maybe sega/nintendo/x86/amiga/atari/etc... Or even at the arcade! Either way, I wanted to check this out on the Commodore 64.

Intricacies of a Datasette Drive

This device has a single cable that plugs onto the PCB edge-connector 'port' at the back of the C64. It's a similar connection to the User Port; very raw and very cheap for Commodore to produce en-mass. The cable also has a grounding wire, but I don't quite know where you'd connect this to?

As you can see, everything was there, ready to hook up and run. I did just that, plugging the tape drive in, the power and TV. Switching it all on brought me to the usual BASIC prompt. I had heard the tape drive make a few faint clicks. The tape needed rewinding, so I let that run it's course (hah, how I don't miss having to do that!)

I'd found out, by accidently typing only LOAD previously, that this was the command to load tapes. After hitting enter, you get a prompt to press the Play button on the tape drive. So, at this point, I did exactly that. As I hit Play on the Datasette, the tape spun, then slowed down... then .... stopped......... Sure, this 30 year-old equipment had been stagnating in someones shed for decades... probably worn-out and dead.

As I was pressing the eject button, the tape started playing again... demons? ghost in the machine? not quite... turns out that a slight bit of pressure on the eject button releases the bottom-right 'guide' that keeps tension on the magnetic tape in the tape case as the tape is playing. This component was able to apply WAY too much tension and therefore effectively 'braked' the tape and cause the motor/band to slip.

'Band', you say? Yes. Band. No belts with teeth here... the drive mechanism is a cute little motor with a rubber band driving the other pulleys. There is then a further rubber band to drive the counter. 'How do I know this?', you ask? ... I took the thing apart as soon as I could!

The bands looked pretty stock-standard. A quick google showed zero results for replacements... so... searching around the house I found some probably-too-small substitutes. Having a band too tight will probably pull on components and put waaaay too much pressure on old equipment that may not be rated for it; but hey, you can only try!

Replacing the main band required 3 screws to be removed. See above. Once removed or loosened, you can slip the main band out.

I then put my two replacements in. Lo'and'behold... the bloody tape started playing. The results? The screen went blue for 15.5 counts, the tape paused and then a message came up: Found Double Dragon! Woah.. then a slight pause and then the tape continued. Then it was ... rubbish?

I gave up after 20s of garbage picture and noise... must be a crap tape or damaged head. But... it did recognise the data on the tape... I mean, it knew the name?

Another Tape: The Android

Along with the datasette drive, I also purchased a 5-tape set of miscellaneous games. I whipped the first one out, named Android and tried it. The C64 successully saw that it was indeed The Android and then ... more crap loading. Loosing heart, full bladder, too much Sapporo... I excused myself, letting it play...

Returned a while later and.. WHAT THE!?... It loaded!? So... wait... those loading images are expected!? That crappy video that would trigger an epileptic fit and that sound that's drilling into my inner-ear is normal?

Android Control (different name on tape vs. name on 'found' vs. name on title?) loaded, I played it for 5 seconds... but I'll try that again later.

Back to Double Dragon

So, now knowing that I need to sit back and wait... I slapped Double Dragon back in again. It took the same 15.5 counts to the Found Double Dragon message and then 58 counts to the next message.

Ok, we're getting somewhere... I hit space...

DAMN! 3 minutes of waiting... first time around the tape actually reached the end... that actually indicates a data issue. Second time around I got the error above. So Android will load, but Double Dragon wont! Might have to clean the heads... Will report back when I have time to try again.

No Comments

2Jun/161

Amiga 1200: Indivision AGA MK2cr

After toying with video output on the Amiga 1200, I'd come to the realisation that old technology just wont display well on brand new TVs. Due to this I therefore researched what everyone else on the interwebs did to get a better resolution from these old beasts.

Results came up quickly and all signs pointed to this device, the Indivision AGA MK2cr by Individual Computers (buy it here.)

This device piggy-backs onto the Lisa chip (the Amiga's Video processing chip), taking the output and then using it's own CPU to convert this to a more recent standard that newer TVs and Monitors can reproduce. It has upgradeable firmware and configurable options. It's stated that, out-of-the-box, you won't need to configure a single boolean value to get it running.

The price isn't low.. but all the reviews I'd read indicated that the value for money ratio was high. I therefore set out in pursuit to find one and came across some hits on Amibay, but watched as faster hawks snapped the prey up VERY quickly.

eBay showed some results also; and then it happened... the exact seller of whom I bought the 1200 from provided the device up for sale. I couldn't resist... Steve understands eBay and had treated me perfectly on the previous sale and so I grabbed this item. Turns out I got a few extra bits too, of which I'll report about later.

Unboxing

The item arrived in record time and it felt like Christmas had come early once again. I knew I had to take my time with this though... opening a ~30 year old piece of equipment (although you could tell it had previously already been modified) required patience and a steady hand.

The box came with all the required components. No software is provided as the device works primarily via its own firmware to detect the video signals being produced by the Lisa chip and convert them out to DVI-capable resolutions.

Installing it

All in all, this was a piece of cake. As mentioned, this Amiga 1200 had been toyed with before and so there was no hassle of breaking warranty seals and the like. Case screws were undone and then the top plate was removed.

I'd previously wondered what the extra DB-25 port was on the left-hand-side (as you look at the back of the machine) and this became clear on opening the case. It's a SCSI port for an accelerator that contains a SCSI interface. As you can see, no such accelerator is in the slot, so the internal end of the cable was sitting loose.

Over near the Lisa chip, I found the CF card to be sitting directly above it. Turns out that there's enough clearance above the MK2cr to have the CF sitting on top, so I unstuck it, flipped it over and stuck the new hardware in place. This went on with a nice click. Even pressure was applied to the center area, where the 4 holes are. Once in place, the cable was run (very tightly, it's the perfect length!) to the location where I'd removed the SCSI plug. Fortunately, I received a 3D printed plate to hold the DVI connector in place. I did need aftermarket screws to secure the plug in the housing; the nuts that were removed from the end of the DVI plug weren't long enough to go through the plastic plate.

First Impression

This always counts... this device was marketed as 'no configuration' ... reminds me of the old 'plug-n-pray' days. Sometimes I miss ISA/EISA cards and their jumpers of which I had supreme control over. Anyway, I hooked up a cheap VGA cable via a DVI-to-VGA adapter and plugged it into the TV. Powering it up... I nearly cried.

The ghosting was immense ... and I truly wasn't expecting this from a Digital product. A quick google lead me to believe that the DVI-to-VGA and then the VGA cable were trashing the signal. I also noted that the resolution being output was 1280x1024. That's a great resolution; but a shitty VGA cable might have issues. I quickly tested the shit VGA cable and adapter on a VGA monitor... it looked better, but still not up to the standard I was expecting.

So, I opened the warchest and found a chunkier cable that had a DVI on one end and a VGA on the other... on the LCD Monitor still showed minor ghosting, as follows...

But on the TV, the ghosting was hardly noticable... Score! This is the pixel-for-pixel that I was looking for.

At this stage I was content with the output... It has since occurred to me that I could convert the DVI to HDMI and keep the signal totally digital. I'll try that and report back soon.

Configuration Options

The 'overscan' area can be customised. On bigger screens, it will default to the background colour of Workbench. You can confgure this using BorderBlank.

Next, resolutions. The MK2cr supports the 'HighRes' driver. Download it here. To install it, move the HighGFX file from the archive to your "sys:devs/monitors" directory and reboot. Higher resolutions should now be visible in the ScreenMode prefs.

If you want to toy with the devices configuration itself, then firstly grab the Flashing tool and v2.6 firmware to see if you have the latest installed. Once you're up to date, you can use the v1.5 Config Tool to configure the device.

From what I understand, you choose the mode on the left and then re-map it to a resolution from the VGA column. Then hit Test/Use/Save. Will update when I tinker further...

The resolutions are awesome. You can find the HD720 driver in the HIGHGFX package, drag that to your dev/monitors folder also. I switched my TV to 16:9 scaling and the resolution looked great!

Time for model train controller programming and games!

1 Comment

27May/160

Commodore 64: cc65 and the User Port

Ok, we've build the user port to parallel port adapter. We've build the parallel port interface. We've hooked a shift register onto it and now we want to control it. Doing this through BASIC would be fun... but compiling real C code and getting this onto the C64 will be thoroughly more enjoyable. Go and download cc65, along with your favourite emulator. VICE works very well on Windows.

Getting a sample running

Before we even think of real hardware, let's get the samples running on VICE. Once you have everything installed, open a command prompt. Switch to the directory where cc65 is installed. Also set your path to the cc65/c64/bin folder. Run cc65 to check if you've got everything correct.

Microsoft Windows [Version 10.0.10586]
(c) 2015 Microsoft Corporation. All rights reserved.

C:\Users\windows_user_1>d:

D:\>cd cc65

D:\cc65>set path=d:\cc65\bin

D:\cc65>cc65
cc65: No input files

D:\cc65>

Download the samples from the github repository and save them nearby. Switch into the samples folder. Choose a sample to compile; I chose ascii. Compile it. Don't expect much from the compiler if there is no error. We're going to use cl65 here which also does all the linking for us.

D:\cc65>cd samples

D:\cc65\samples>dir

 Volume in drive D is Data
 Directory of D:\cc65\samples

26/05/2016  12:40 PM    <DIR>          .
26/05/2016  12:40 PM    <DIR>          ..
17/05/2016  02:26 PM             2,300 ascii.c
17/05/2016  02:26 PM             8,068 diodemo.c
17/05/2016  02:26 PM             2,455 enumdevdir.c
17/05/2016  02:26 PM             6,928 fire.c
17/05/2016  02:26 PM    <DIR>          geos
17/05/2016  02:26 PM             6,592 gunzip65.c
17/05/2016  02:26 PM             1,956 hello.c
17/05/2016  02:26 PM             3,772 Makefile
17/05/2016  02:26 PM             3,711 mandelbrot.c
17/05/2016  02:26 PM             7,345 mousetest.c
17/05/2016  02:26 PM             6,236 multidemo.c
17/05/2016  02:26 PM            69,766 nachtm.c
17/05/2016  02:26 PM             3,117 overlaydemo.c
17/05/2016  02:26 PM             8,573 plasma.c
17/05/2016  02:26 PM             5,865 README
17/05/2016  02:26 PM             2,876 sieve.c
17/05/2016  02:26 PM             5,269 tgidemo.c
17/05/2016  02:26 PM    <DIR>          tutorial
              16 File(s)        144,829 bytes
               4 Dir(s)  1,717,242,986,496 bytes free

D:\cc65\samples>cl65 -O -t c64 ascii.c

D:\cc65\samples>

Quickly check that there's a binary called 'ascii' in the folder with no extension.

D:\cc65\samples>dir

 Volume in drive D is Data
 Directory of D:\cc65\samples

26/05/2016  12:52 PM    <DIR>          .
26/05/2016  12:52 PM    <DIR>          ..
26/05/2016  12:52 PM             2,648 ascii
17/05/2016  02:26 PM             2,300 ascii.c
26/05/2016  12:52 PM             2,767 ascii.o
...

You've got a compiled application! Let's run it. Open up VICE (x64.exe is the c64 version) and choose File -> Autostart disk/tape image. You'll need to browse to where you compiled the sample and set the filter to all files.

Once you see 'ascii' (or whatever you compiled) double-click it.

Feel free to play with the other samples and see what C code is available and explained.

Poking the Port

BASIC had two commands that altered system memory. PEEK and POKE were essentially READ and WRITE. They allowed the user to change values in RAM or read values back. Hitting certain addresses did certain things. Specifically, on the C64, POKING 56579 altered the input/output configuration of the User Port and then POKING 56577 changed the values being sent.

To do this in C, we need equivalent functions. Fortunately, the cc65 wiki has all the information we need. It turns out that no function is required, you can simply write to ports by setting the address (via a pointer) to the value you require. To make it a little less difficult to read, they've also provided macros to do the same thing. They'll help when you come back to the code 6 months down the track and can't read a thing you wrote!

    #define POKE(addr,val)     (*(unsigned char*) (addr) = (val))
    #define POKEW(addr,val)    (*(unsigned*) (addr) = (val))
    #define PEEK(addr)         (*(unsigned char*) (addr))
    #define PEEKW(addr)        (*(unsigned*) (addr))

There's also pokes for 'WORDs' there, but we don't really need them. Look here for a huge list of what you can PEEK and POKE. Turns out there's more memory address to poke here.

Note: These defines are also in peekpoke.h, just include that!

Moving the cursor

By default, as per CMD or any other Console, the text just rolls down the screen. Scrolling (with a buffer) is something that you actually need to implement in C64, so either start preparing for a buffer, or just get ready to use a single screen and clean up after yourself.

I want to draw a diagram of the 8 LEDs I'm about to control, so for this purpose we'll need to be able to place characters at certain positions. This involves moving the cursor to the required location and then outputting the character.

Fortunately, functions are already there to do all this... just use the gotoxy as per the source listing below.

Controlling the parallel port and 74HC595

So, we now have everything we need to write out the data required to control the 595. I'll just list it below. There's more information back here on how it actually works.

#include <stdlib.h>
#include <string.h>
#include <conio.h>
#include <joystick.h>
#include <peekpoke.h>

#define USERPORT_DATA 0xDD01
#define USERPORT_DDR  0xDD03

static const char Text [] = "Train Controller!";

void shiftout(int val)
{
	int i = 0, zzz = 0;
	for (i = 7; i >= 0; i--)
	{
		POKE(USERPORT_DATA, (val & (1 << i)) == val ? 1 : 0);
		POKE(USERPORT_DATA , 2);
		for (zzz = 0; zzz < 1000; zzz++) {}
		POKE(USERPORT_DATA , 0);
	}
	POKE(USERPORT_DATA , 4);
	POKE(USERPORT_DATA , 0);
}

int main (void)
{	
    unsigned char XSize, YSize;
    int i = 0, z = 0, zz = 0;

    //set all pins to output.
    POKE(USERPORT_DDR, 255);
		
    /* Set screen colors, hide the cursor */
    textcolor (COLOR_WHITE);
    bordercolor (COLOR_BLACK);
    bgcolor (COLOR_BLACK);
    cursor (0);
	
    /* Clear the screen, put cursor in upper left corner */
    clrscr ();

    /* Ask for the screen size */
    screensize (&XSize, &YSize);
	
    /* Top line */
    cputc (CH_ULCORNER);
    chline (XSize - 2);
    cputc (CH_URCORNER);

    /* Vertical line, left side */
    cvlinexy (0, 1, YSize - 2);

    /* Bottom line */
    cputc (CH_LLCORNER);
    chline (XSize - 2);
    cputc (CH_LRCORNER);
	
    /* Vertical line, right side */
    cvlinexy (XSize - 1, 1, YSize - 2);

    /* Write the greeting in the mid of the screen */
    gotoxy ((XSize - strlen (Text)) / 2, YSize / 2);
    cprintf ("%s", Text);
	
    /* MARQUEE */
    for (zz = 0; zz < 4; zz++) {
        for (i = 0; i < 8; i++) {
            shiftout(1 << i);
            for (z = 0; z < 8; z++) {
                gotoxy (((XSize - 15) / 2) + (z * 2), (YSize / 2) + 4);
                cputc((z == i ? 'X' : '_'));
            }
        }
        for (i = 7; i >= 0; i--) {
            shiftout(1 << i);
            for (z = 0; z < 8; z++) {
                gotoxy (((XSize - 15) / 2) + (z * 2), (YSize / 2) + 4);
                cputc((z == i ? 'X' : '_'));
            }
        }
    }

    /* Wait for the user to press a key */
    (void) cgetc ();

    /* Clear the screen again */
    clrscr ();

    /* Done */
    return EXIT_SUCCESS;
}

Note: some cputc calls reference defined characters such as CH_URCORNER, etc... These are PETSCII, the embedded character set of the Commodore. The wiki page has the numbers for the characters. Go to the include folder of cc65 and then cbm.h to see if the character is defined, otherwise just put the value in as a raw number.

And the result.. the bloody thing worked first go. Pretty scary actually... compiling and executing C code on the C64 was too easy. Of course, I cheated by using an SD2IEC. The load command was LOAD "0:TRAINCTL",8 followed by RUN.

You'll note that my keys are still on order... I can't wait for them to arrive as pressing 8 is tedious. Also that the last shot shows two Xs lit. Blame shutter speed and screen refresh times.

What's next?

Maybe it's time to hook up the serial port? nanoflite has provided a C driver which may well help us. Otherwise it's time to write a real railway controller for the parallel port interface... but I should actually finish that first.

No Comments

26May/160

Commodore 64: Wiring up the User Port

The User Port on the Commodore 64 is a combined parallel port + serial port. Both of these can be used after a little wiring effort. Memotronics has the ports available, with nice handles. The handle is imperative for ease of removal. You really don't want to be pulling on wires to unplug anexternal device! I purchased this and also couldn't resist the 200 random LED bag.

User Port Socket Alignment

There's a row of letters and a row of numbers... make sure the numbers are along the top. Looking at the back of the C64, you'll notice there's two slots for socket alignment. To the right are two pins, then the center block, then 1 pin on the left.

Yes, the socket is plugged on upside-down in that middle picture!

The socket from memotronics comes with two white spacers in a plastic bag. Slide them into the slots appropriate for each side of the socket. Once done, tin up your wires and solder through to the parallel port.

Connecting it to our circuit

The whole reason behind this is to control the circuit described here and here. The goal was to use a standard interface, being the parallel port. The Amiga and the PC happily work; the Commodore was next. As mentioned above, the data pins are there, we just need to wire it through.

One really good point: once you've attached the wire to the parallel port end, draw a black line down pin one to the other end. Knowing which wire is which will get confusing once you've jammed it through the user port socket 'cap'. I actually surprised myself expecting to see the black line elsewhere and was glad I'd drawn it.

With the User Port socket in hand, I reviewed a few documents to work out which pins did what. All pinouts was a good source, until I realised that 'I' was missing. I assumed they got it wrong and so went searching further. The c64 Wiki has a pinout also, which also doesn't include 'I'. What's that old saying? No 'I' in 'Team'? There's no 'I' in 'User Port' either...

One quick check elsewhere at hardwarebook.info told me that the port I had from memotronics, which has an 'I', is incorrect. So... just make sure that the

The 'middle' 8 lower pins of the socket are the data pins that 1-to-1 match D0-D7 of the parallel port. You can then use Pin 1 and 12 to GND on the parallel (18-25) and yes, 17 is GND, but not on Amiga!

Putting it all together

Everything plugged together nicely... I powered up the circuit first; you should always make sure perpipherals are powered on first, prior to turning on the C64. Either way, LEDs lit as per usual and then it was time to hack in BASIC. You can see on the screen that I tried to output an 8-bit binary value to the 595... but the results weren't stable. It was late and I'd accomplished the first task: The pins were wired in and the LEDs between the optos and the C64 lit as expected!

What's Next?

Either I continue hacking BASIC and get the 595 driven, or I use something like cc65 and write real C. I think I'll go the latter. I also want to hook up the Serial port here... so I'll extend my little dongle to have a serial port hanging out of it also.

See this post on cc65 for an example of how to program the Usre Port via C!

No Comments

21May/160

Amiga 1200: An Introduction

I'd happened across the Commodore 64C at the local flea market not by fluke, but because I was looking for Amiga controllers. I'd recently won this beautiful piece of equipment on eBay and was awaiting its arrival. The auction included an LCD TV adaptor, one joystick, a demo floppy and an LCD monitor.

Unboxing the loot

This thing is huge. It's form-factor is quite similar to the C64C, but scaled up. This specific instance isn't overly yellow and is in really great shape. It was very simple to hook up, a power supply and a video cable. I remember seeing the TV Box plugged through on the pics in the eBay auction, so I tried that out first.

The TV Box has VGA in/out, I assumed this was to be used and hooked it up. No picture... on anything... The LCD monitor that it came with also didn't work... but I knew that this was meant to work; must've been doing something wrong. The LCD reported that the scanrate of 15.6khz was too low. I happily agreed with that.. as it was hideously low for VGA standards.

After a little googling I realised that the video port, plus VGA adapter, would only put out the standard PAL/NTSC ~15khz signal. This would never work, so I fed composite in to the TV Box. Yey! A picture!

Getting a decent picture

This turned out to be a lot harder than I'd expected. After toying with the TV Box, a lot, I'd realised that it wasn't going to work. I then tried feeding the composite signal from the Amiga straight into my LG TV. This worked, but still looked shite. Turns out there's all sorts of settings to get a good picture.

First, you need to dig into the preferences folder in Workbench. From here you can select ScreenMode. You'll find a whole lot of resolutions listed and they were totally foreign to me. It seems that, back in the day, there were all sorts of hacks to get more pixels displayed on CRT monitors. As that these TVs were more or less 'programmable', you could tune the electron gun to whatever resolution you wanted. I wonder how many TV warranties were voided due to bad choices from this menu?

Either way, there were options that indicated 'double-scan' which produced a much cleaner picture... even a (or so it seemed) higher resolution. I really don't quite understand resolutions over composite video, but it looked better!

Next I tried to run the demo disk of Jungle Strike from workbench and it failed miserably. Turns out this works fine when booted straight from the floppy (or so I accidently found out!) I wonder if you have to set the workbench resolution to something hideously low prior to starting specific games?

Welcome to the workbench

Either way way, we'd now made it to the workbench. I clicked around trying to understand how it worked. I've never used a GUI on an Amiga before and this was all startlingly new!

A right-press seemed to bring up a context menu, when held down, but along the top of the screen. The text was fuzzy and hard to read, but resembled the old MacOS quite a bit. Some useful commands up there, but no power options (restart, shutdown, etc...)

The icons all allow a single click, this then 'highlights' them... well, it actually presses them in. I take it this means 'selected'. You double-click them to execute/open. Any alerts/warnings are displayed along the top menu. Speaking of which, this reports the memory free on your system (something we haven't cared about in the PC realm for a REALLY long time) ... so you know if you can start that next program or not.

Floppy disks

The A1200 has a Double-density 3.5" floppy drive. You'll be hard-pressed to find such disks around the shops nowadays, but don't freak out... you can use High-Density disks also. Of course, good luck finding those too!

With a High-Density disk, make sure the label is facing you and tape over the top-left 'hole'. Floppy drives have an optical sensor which, when light transmits through this hole, indicates to the drive that the disk is High-Density. If the light is blocked, then the disk is taken for a Double-Density.

With the hole taped over, make sure the that the top-right write-protect switch is also covering the hole. If light can shine through this hole, then the drive will think that the disk is write-protected and the disk will be read-only.

Making an Amiga floppy from Windows

To be blunt; you can't do this. What you can do is create a PC disk from the Amiga and then use it on the Windows side to transfer the files across. Once you have a double density disk, as mentioned above, then you're ready to go.

I tried to create/format a PC disk from Windows; but I crashed explorer each time I tried to format it. It seems that explorer only wants to see HD floppies in the drive. Using the tape trick (as above) and then trying to format just did not work!

Making a PC floppy from Amiga

Yes, we have to do this backwards. Grab your taped up fake DD floppy disk and slap it into the Amiga. Chances are, depending on the state of the disk, you'll get a DF0:????? icon on the workbench desktop. Double-clicking this will result in "No application associated to this item" in the workbench title... or something similar.

Firstly, you need to enable the CrossDOS extensions. Browse to your boot HDD, then the Storage/DosDevices folder. Copy the PC0 file to Dev/DosDevices on your HDD. Pop the disk back out and reboot the Amiga (CTRL + A + A.) Once you're back at the workbench, insert the floppy. You should now see PC0:????? and DF0:????? on the workbench. Disregard both of them.

Browse back to your HDD and open System. Here you'll find the Format application. If you choose PC0, then you'll format the disk as a PC disk. Alternatively, if you choose DF0 then you'll format it as an Amiga disk. This kind of cross-platform functionality is actually astonishing foresight from the Amiga developers at the time. Seriously helpful.

Once the format is complete... savour the sounds, there's nothing quite like a floppy drive at work... you'll have a disk that you can now use in Windows. It's capacity will be 720kb, so bare with a bit of disk shuffling to get the data across.

So then, how to I play A-Train?

Firstly, you need the ADFs from somewhere... if you know of google, then you'll be fine. Acquiring these images will, usually, mean that they're then marooned on your Windows PC; we'll need to get them over to the Amiga somehow. A-Train happens to be two disks. Each ADF image is a full Double-Density disk size, and therefore can't be copied onto one as-is. Formatting PC disks on the Amiga, as above, won't leave youwith enough space to copy either ADF onto a single disk. Therefore, the best method here is to copy the A-Train zip onto a floppy and then copy this zip onto the Amiga. You'll then need an unzipper and an ADF-to-floppy writer.

Copying files to the Amiga

So, just like that old joke of the farmer, the sheep and the wolf... how then do we safely get them all across the void to the Amiga without them eating eachother? Simple. Drag and drop!

Head back to the Workbench and insert your PC-Formatted Double-Density Floppy Disk with an A-Train ZIP on it. On the workbench you'll still see DF0:?????; disregard this. You should now also see a new icon with a CrossDOS icon and an 'EMPTY' title.. unless you named the floppy, somehow, when you formatted it.

Open the floppy and view the contents... A-Train.zip should be there. Drag it to your HDD.

Once copied, view the HDD and ... wait ... where is the file? It took me a while to work out that Workbench only likes to show 'Drawers'. Hold down your right-mouse-button and view the menus up the the top. Under one of them you'll find the option to view all files, or just Drawers. Select all files.

Now you'll see your zip file on the Amiga. Unfortunately, Amiga's native compression application is LHA... it doesn't deal with zip files... so we're stuck.

Zip files and the Amiga

Or are we? Turns out there's a crapload of software for the Amiga just waiting for us to ferry across from our Windows machine! Browse to Aminet and download Unzip v5.40.. or any other version of your choosing. Once you have this file (YOSH! It's an LHA!), copy it to the floppy (you can delete A-Train.zip, it's already across the void) and transfer it to your Amiga HDD.

Go to System on your HDD and you'll find 'Shell'. Double-click this. Welcome to the console/shell/command-prompt. This acts very much like any other DOS that you've had to deal with. The goal here is to lha -d UnZip.lha (turns out it's not case-sensitive) to get to your new Un-Zipper!

Once extracted, you can shift into the Unzip directory by typing cd Unzip_v5.40. In here you'll find the application UnZip. This simply wants a zip file as it's argument to extract. Type UnZip [hdd_name]:A-Train.zip.

It'll take a while, but you'll now have two ADF files sitting in your Zip programs folder. Not overly clean, but we can delete them later once we've written them to real floppies.

Writing an ADF file to a floppy from the Amiga

A-Train needs two floppies. Find two blank ones. No need to worry about formatting, but make sure they are Double-Density! If you've only High-Density, then tape them up as per the trick above.

Once you have two ready to go... browse to Aminet again and you'll find a lovely application called ADF2DISK. Again, it's an LHA, so we just need to get it on the floppy and across to the Amiga.

Once there, extract it as you did Unzip (not as you did A-Train!) and then browse into the directory. You should find an application called ADF2DISK.

Now that we have the app, we need to insert a floppy (doesn't need to be blank, but its content WILL BE OVERWRITTEN!) and run the following command: ADF2DISK [hdd_name]:UnZip_v5.40/ATRAIN1.ADF. I might have the A-Train Disk 1 ADF filename wrong there, so just make sure you get that correct.

As per usual... sing along with the beautiful sounds of your floppy drive and wait for the 'burning' to complete. Once done so... eject it and burn the second disk.

Playing A-Train

For some reason, re-inserting the disk wouldn't work. It's like Workbench was trying to be too smart and cached what it thought they disk should contain. In this case, nothing, as they were crap disks to start with. Maybe I was being to hasty, maybe you need to wait a bit before ejecting/inserting disks.

Either way.. I restarted it with Disk 1 inserted and, lo-and-behold, the disk worked and booted into an archaic Workbench (via a lovely demo-scene intro stating who the evil people where who made this all possible) with the A-Train icon just waiting there to be double-clicked. There was also an installer application!

I didn't want to run from floppy, so I popped the disk out, rebooted the machine and then inserted it again. It happily appeared on my Workbench and I could install from there.

After that, I browsed to the 'Drawer' it created and ... bang ... double-clicked and she was off and running!
... now to remember how to play the game!

What next?

Turns out this unit is highly expandable. You can insert daughterboards in the 'trap door' underneath which increase RAM and/or CPU. There's also a Parallel Port, so I think I'll make the model railway interface that I discussed back in the C64 article work on both machines.

I'll add articles and links to the list below when I get around to writing them!

RAM Cards: This machine needs more RAM. It comes with 2mb on-board 'chip ram', but Workbench 3.9 needs more.
More information here...
OS: This unit is currently booting into Workbench 3.1. I've seen some great eye-candy of 3.9 screenshots and want to run it. Seems it needs more RAM. It also needs a newer Kickstart ROM. The ROM is ordered... more research required for the RAM.
HDD: Maybe a bigger one? Seems I have a CF in there with 512mb of disk. Will need a re-partition or renewal for OS 3.9
VGA: This needs to be done. I want pixel-for-pixel. Information here and here.
Games: Day of the Tentacle, etc...
Accelerators: Where to start with this? Watch Majsta for something insane shortly!
Parallel Port: Build an interface for the model railway. Use it for the Commodore too... parallel port information here and here.

Again, these machines are awesome to work with.

No Comments

18May/160

Commodore 64C: An Introduction

I've had a hankering for an Amiga for a while now... I don't know why.. I think it has something to do with the accelerator that was made for the Amiga 600 that made it go faster than ever thought possible... sure they emulate the entire core in a much faster CPU and high-jack the motherboard... but it's still an awesome feat!

I also have a feeling that I missed out on a whole realm of computing in my childhood by following the Nintendo/IBM route. I'm pretty sure there was a-whole-nother world out there... Sega, Amiga, Atari, TI, etc... that I never got to sample. Actually, I lie... my neighbour had a TI-99/4A, followed by a Sega Master System... but I only ever got to play them briefly. Hunt the Wumpus was random, but fun at the time!

My first Commodore

Officially, this is my second. The first was purchased in the mid-90s at a fair at high school, but didn't work. It was the original breadbox style and was stone dead. Should've left it in the garage!

Anyway, this past weekend I spied a box of junk at the local Trash and Treasure and actually thought I saw an Amiga 500/1200. Instead it turned out to be the 'newer' C64. I was hooked.

The guy wanted $100 for the box. It contained:

C64C (missing 3 keys) + Power Supply
Composite Video Cable with Stereo Audio
Two quickshot joysticks
One control pad (looks like a NES clone)
3 odd cartridges
Another odd console named 'Tempest'
1571 External Floppy Drive

Now that I list it, it could well be worth the AUD$100. I offered $50. He haggled back to $60... knew I had him. Asked if it worked... he had no idea... so I pulled change from my pocket and made a deal at AUD$52.

Bargain.

Does it work?

Worked first time... plugged it in and switched to A/V input... blue screen of dea... BASIC!

Random 4s and 8s on the screen... and the cursor was stuck hard-left. This directly mapped to the keys that were missing. 4, 8 and HOME. Turns out that there is no spring when the keys are off, so these were all 'pressed'.

Got some tape, placed along the shaft of the missing keys to hold them in the air. Restarted... it works! Quick search on eBay on my phone, from the couch, in front of the LCD TV that was happily displaying technology from 1987. Found replacement keys... ordered them on the spot.

Next google to a sample BASIC app... found a tone generator. Tedious data-entry thanks to taped-keys... but it worked beautifully through the surround system. Hah.

How much more powerful is my phone than this? No idea.

1541-II Floppy Disk Drive

This is external and has its own brick of a power supply. Turns on and hums away when I attempt to access a disk... so I assume it's in working order. There's disks on their way via eBay, so I'll test it out shortly.

The innards

See below for the case opened. I was curious as to why it had a green LED. Turns out Commodore could never work out what colour the LED should be. The warranty seal was also very well voided. Seems to be some newish solder around the PAL/NTSC circuitry... maybe this was a conversion?!

Turns out I have an Assy 250469 Rev. B. Built in 1990 (assumed by the scratched out '91' on the RF Modulator.) This model was still being built in the '92, so I seem to have acquired one of the final models.

What's next?

Yes, that's a model railway under the C64C... I will control it. Turns out I bought a book when I was young that was all about robots and the Commodore 64. I need a VIC-REL or equivalent. Bugger that... let's find the header for the user port and make my own!
Buy floppies (thanks eBay) and test out the drive.
Buy some form of flash disk and play all the games I missed out on. I chose the SD2IEC... waiting for it to arrive.
Serial port? Modem? Ethernet?
What else?

This is fun!

No Comments

« Newer Entries

Random Photos

Approaching Burbong

AK Cars from Tarago to Canberra
Photo Album Index

modelrail.otenko Trains, computers, vintage, retro, model railways… the lot…

Designing a communication language

Talking back to the Terminal

The Command Table

Code for the Arduino

Controlling with a Commodore 64

What's Next?

Interfacing both components

DTE vs. DCE

C64 Serial Port

Arduino Serial Port

Hooking it all together

Testing with Strike Terminal 2013 Final

Writing C code to use the Serial Port

Powering the SD2IEC from the Datasette Cable

Cleaning the head

Aliging the head

Back to Double Dragon

Choosing a CF Card

Partitions

Installing and Configuring WinUAE

Creating Amiga Partitions

Installing Workbench 3.1

Other patches

Workbench 3.9

Boing Bags

Extra features

The Datasette drive arrives

The first game: Double Dragon

Intricacies of a Datasette Drive

Another Tape: The Android

Back to Double Dragon

Unboxing

Installing it

First Impression

Configuration Options

Getting a sample running

Poking the Port

Moving the cursor

Controlling the parallel port and 74HC595

What's next?

User Port Socket Alignment

Connecting it to our circuit

Putting it all together

What's Next?

Unboxing the loot

Getting a decent picture

Welcome to the workbench

Floppy disks

Making an Amiga floppy from Windows

Making a PC floppy from Amiga

So then, how to I play A-Train?

Copying files to the Amiga

Zip files and the Amiga

Writing an ADF file to a floppy from the Amiga

Playing A-Train

What next?

My first Commodore

Does it work?

1541-II Floppy Disk Drive

The innards

What's next?

Random Photos

Search

Tags

Ads

Archive

Meta