May « 2016 « modelrail.otenko

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

26May/160

Parallel Port: Shift Registers

Now that we've controlled a LED by a single pin on the Parallel Port, it's time to expand our abilities. The goal of this post is to describe the usage of Shift Registers and then consume a minimal amount of pins, 3 out of the 8 available, to control up to 64 outputs!

A Shift What?

So, you have 8 digital input/output pins on the Parallel Port. This isn't the greatest amount and it'd be really nice to extend the amount available. There are a few ways, but a popular method is to employ a shift register.

A shift register is an IC which takes a 'serial' input and then outputs this on it's output pins in 'parallel'. By 'serial', we mean that the IC accepts input data on one pin only. This data is provided by you, as either a '1' or a '0'. Once you've set the value on the input pin, you then toggle another pin, known as the 'clock' pin, to tell the IC that the data is ready to be consumed.

The shift register, once the clock pin is toggled to a '1' and then back to a '0', will look at the input pin and then copy this value into it's internal register. We're using a 74HC595 which has 8 internal registers and therefore 8 output pins. At this point, the IC shifts all values on it's 8 internal registers up one slot and then sets the very first internal slot to the value you've provided.

You can then provide 7 more values, toggling the clock pin between each, an the IC will shift them along it's internal registers. What you've now done is set an 8-bit value inside this IC. Once the IC contains the value you've requested, you toggle the 'latch' pin and the IC will shift these 8 values out to the 8 output pins. These are known as 'parallel' as there is a single pin for each value; as opposed to the input which is serial (or one-after-another) on a single pin.

So, we've used 3 pins/wires here to control 8 output pins... pretty neat hey? We've turned our original 8 Parallel Port pins into (8-3) + 8... 13!

But wait, there's more! There's an 'output' pin on the shift register that reports the 'shifted off' value. What can you do with this? Feed it into a neighbour shift register as the 'input'. Hook up the same clock/latch wires as the first register and then, when you shift the 9th bit into the first, the very first bit you shifted in will be shifted out of the first register and into the second.

This means that, with the same 3 wires, you now have 16 outputs! Of course, you can keep doing this. I can't find anywhere that mentions how many you can effectively chain up. Of course, as you add more, the time to toggle out the values increases and you need to make sure that your code/hardware has time to think about other things instead of spending it all talking to the shift registers.

Connecting it to our previous circuit

We only used one line of the parallel port in the previous circuit and therefore only controlled one LED. For this first shift register, we'll need 3 lines. First thing is to hook up three LEDs with matching resistors. We could just hook two other lines up direct to our new shift register, but I like being able to visualise the data (and troubleshoot issues!)

With this circuit, you'll be able to use the sample code in the previous post to control the 3 LEDs.

Sending out a 1, 2 or 4 should switch them on individually. Sending any combination of these, by adding them together, will turn on the associated LEDs. For example, sending out the decimal value 3 will switch on the first and second LED. The value 5 will switch on the first and third LED. As the value makes it to the port, it is split into it's individual bits, which are then translated to the data pins.

Once these are working, we're going to splice in some opto-couplers. We don't want any untoward voltages getting back to the parallel port. Optocouplers contain an LED and an internal light sensor. When power is applied to the input, the LED lights and the light sensor receives the signal. This is then output to the secondary circuit. This effectively provides an 'air gap' between the two circuits.

From these couplers we can control our shift register(s). Hook the three outputs to the 74HC595 shift registers SERIAL, CLOCK and LATCH pins. Remember the order as they each play key roles (as per the description of how they work above.)

Once you're ready, check that the three input LEDs react accordingly to basic Parallel Port data. Note that you may get erroneous data coming out of the shift register from the get-go. Data coming off the Parallel Port during system boot cannot be controlled and may cause havoc. We'll do something about this in a later article.

Building this required a LED array... you could do it easier and get one of those bar-graph arrays. Wiring up all the individual LEDs gets a little tricky.

Controlling the data output

Based on the initial description of the shift register, we know that we have to control the 3 data lines in a special sequence. First thing we need is an 8-bit data value to send out. Once we have this we can send each data bit out via the SERIAL line; toggling the CLOCK signal in-between. Finally, toggling the LATCH should see our value displayed in a glorious binary LED representation!

I've used Windows and the Parallel Port code here to manually try and turn on LEDs. My wires are hooked up as D0:SERIAL, D1:CLOCK and D2:LATCH. I am going to send 00000001 as the value to ensure that all LEDs are turned off bar the first.

Ensure that LATCH is low (red)
Toggle D0 to RED, this is a '0' for the first bit of the serial value.
Now toggle the CLOCK (D1) on and off 7 times.
Toggle D0 to GREEN.
Toggle the CLOCK on/off once more.
Toggle D2 on and off...

If everything is hooked up, then you should now have one LED showing on the output of the 74HC595. It didn't quite work with this initial circuit... LEDs would light a little randomly.

Noise

Although the above circuit worked, it was not reliable! Every now and then one LED (or two) past the one I wanted to switch on would also switch on! Sure, my soldering was dodgy, let alone the wiring also being messy. Either way, noise was being introduced and the flipping of the serial and clock was jumbled, causing random output.

The solution to this was to put a 100nf capacitor across the +5v and gnd supplying the 74hc595. This cap should be put as close to the IC pins as possible. Once in place, this stabilised the data from the PC Parallel port.

References

- HowTo: Understand the 74HC595 (David Caffey)
- Gammon Forum: Using a 74HC595 output shift register as a port-expander
- protostack: Introduction to 74HC595 shift register – Controlling 16 LEDs

What's Next?

Next is a 12v throttle. I intend on using the described sample here. The only issue is that it wants a potentiometer to vary the output voltage. This is an analogue method; we'll convert it to digital by calculating 8 resistor values to imitate the throttle at 8 positions.

I'll write this up soon once I've completed the circuit.

No Comments

22May/160

Parallel Port: Model Railways

Am sure this has been done 100 times before, but I've recently acquired two relic computers and I want them to control my trains. They both have ports consisting of 8 digital I/O pins and I'll utilise these to control a throttle, direction and points. I'll also use them to read sensors.

Having only 8 pins provides a nice challenge... but nothing a few shift registers cannot handle!

First step, LEDs

Let's get started very simply by switching a LED on and off. One might think that, as that LEDs are synonymous with digital electronics, that one can just hook it up to a digital pin and set the output to HIGH. One could... but the current draw would likely kill the 'controller' that the parallel port relies on!

Due to this, you must make sure that you provide sufficient safeguards to prevent damage to your delicate hardware. Once you trash a parallel port in a system (especially of this vintage), you cannot go back.

The trick we'll use is known as opto-coupling or opto-isolation. The goal is to use ICs that have both a LED and a light sensor inside them. When you trigger a HIGH state on the LED side, the light sensor is activated and the associated HIGH state is seen on the output side.

This effectively isolates the electrical circuits and prevents any unweildly voltages on the 'peripheral' side from trashing your valuable hardware.

Thanks to Ian Stedman, we can use the circuit he has provided to hook up LEDs and opto-couplers.

The Amiga port provides a lower current than most PC Parallel ports, so we'll use it as the lowest denominator when creating this circuit so that we can use this hardware across multiple platforms.

(Excuse the paint-brush infancy!)

A 74HC7404 Hex Inverter is used to 'sink' the current used by the LED or Opto-coupler. This IC is much more capable of handling the current and will link the GND wires together internally rather than sending the GND signal back through the parallel port to be linked inside the Amiga (or other device that you've plugged this in to.) This provides a secondary level of protection.

The circuit was built on a crappy prototype board; I seem to have misplaced my breadboard. I used ribbon cable and a standard DB-25 male printer port plug. I've left room for future expansion. I had some spare RGB leds, so the red light is showing that 5v is available and green indicates a 'LOW' output from D0 (or pin 2 of the parallel port.)

Controlling it via code

Thanking Ian again, he's provided us links to demonstration code to test out the circuit we've just created. Download the first sample here.

This sample provides a compiled version of 'Pario' which is a C program to test the parallel port on the Amiga. This code is for the console, so extract it and then run the PARIO/PARcode binary.

Excuse the quality of the photos... haven't learnt how to take screen captures on the Amiga and photographing an LCD TV isn't easy.

Either way, once the program is loaded you'll get a list of options... Press 1 then enter then set the ports to output. Then Press 2 and enter either FF or 00. This is a blanket 'all on' or 'all off' for the 8 data pins.

Doing this made my LED successfully light up and turn off! Winner!

Cross-platform: PC test on Windows 7

This wasn't fun. First I had to re-image my Lenovo X61 as it had a huge amount of spyware on it after lending it to a friend. Then I had to make LPT1 work. Device Manager indicated that all was swell, but the sample code from Code Project just didn't work. On reboot, the green LED would flicker, so I knew that the port was live and communicating.

I dug deeper and tried a second example, using TVicPort, but this also didn't work. I went into the BIOS and found the port disabled!?! Why did Windows tell me it was fine?

After enabling it, there was still no dice. I dug through the sample code and it all seemed to set the port into ECP mode. Was this the same as "bi-directional" which was the default setting in the BIOS? Had no clue.. so back into the BIOS where this could be changed to ECP. Had to be it!

And blam! It works. Hitting D0 on the first sample app works a treat!

Cross-platform: Making this work from the Commodore 64!

My User Port interface for the C64 arrived and I decided that using BASIC was going to provide a good challenge. I've also now coded the User Port in C.

With the hardware hooked up, I ran the following sample to control the LEDs. A thanks to Coronax for the initial example.

Originally the code was to test all values up to 255, or 11111111b. We only need to test the first three pins in our case, so going to 7 (or 111b) will iterate through the values as expected.

Line 20 sets the magical address 56579 to 11111111b. This means that all 8 pins are '1' or 'output'. 56577 is then the I/O for the port and setting a 0 or a 1 provides a digital LOW or HIGH respectively.

10 PRINT "USER PORT EXAMPLE"
20 POKE 56579, 255
30 FOR I = 0 TO 7
40 POKE 56577, I
50 FOR J = 1 TO 150: NEXT J
60 NEXT I
70 GOTO 30

Does it work? Yes... Check out more on coding the User Port here.

What's next?

Next is a shift register... with the ultimate goal being a minimal-pin-usage 12v throttle for the railway. Stay Tuned.

Filed under: Code/Electronics 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

Random Photos

DSC09637

Yokokawa - May, 2019
Photo Album Index

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

Commodore 64: cc65 and the User Port

Getting a sample running

Poking the Port

Moving the cursor

Controlling the parallel port and 74HC595

What's next?

Commodore 64: Wiring up the User Port

User Port Socket Alignment

Connecting it to our circuit

Putting it all together

What's Next?

Parallel Port: Shift Registers

A Shift What?

Connecting it to our previous circuit

Controlling the data output

Noise

References

What's Next?

Parallel Port: Model Railways

First step, LEDs

Controlling it via code

Cross-platform: PC test on Windows 7

Cross-platform: Making this work from the Commodore 64!

What's next?

Amiga 1200: An Introduction

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?

Commodore 64C: An Introduction

My first Commodore

Does it work?

1541-II Floppy Disk Drive

The innards

What's next?

Random Photos

Search

Tags

Ads

Links - Click for details

Archive

Meta