Video: Reviving a dead Amstrad CPC 664 – The Egyptian mummy

Introduction

I bought this CPC 664 from ebay, it looked nice but it was advertised as “for parts or not working”. It came from Cairo in Egypt as was evident from the dust all over the motherboard and inside…

As it was dead on arrival I decided to name it the Egyptian mummy.

 

I actually received the 664 in January but spent a few weeks researching the problem on Amstrad Wiki forums. The advice I got there was excellent (from Bryce, Noel & others), so I went and ordered some parts from ebay and watched countless videos about replacing RAM on Amstrads’ (hint, start with Noels excellent videos @ noels retro lab).

Note that no matter how many videos you watch about repairing old retro computers, the best way to learn what works for you is to try it yourself, and to learn from your own mistakes. I should know, I learned a few tricks in the hours it took de-soldering the ram on this CPC.

Here are the new parts I ordered in no particular order. All of the parts listed below are by random sellers that have nothing to do with me, I’m just posting the links so you can find something similar yourself.

FDD cable – https://www.ebay.co.uk/itm/Disk-drive…​
Keyboard membrane – https://www.sellmyretro.com/offer/det…​
Hot air gun – https://www.ebay.co.uk/itm/WEP-858D-H…​
RAM chips – https://www.ebay.co.uk/itm/233803225716​
RAM sockets – https://www.ebay.co.uk/itm/50PCS-16-P…​

I already had some other tools, so in case you are interested here they are.

Desoldering Sation – https://www.ebay.co.uk/itm/Brand-NEW-…​
Weller WECP-20 soldering station – https://www.ebay.co.uk/itm/Weller-WEC…​

Posted in CPC 664, Egyptian mummy | Leave a comment

Ram tests and more with the Dandanator from Hobby Retro

Introduction

I’ve heard a lot about the Dandanator from various websites so decided to get myself one. This device is designed by a very clever guy called Daniel Leon and is available as an open source project for anyone to make.

After filling in a contact us form at the bottom of a webpage I got an email response from MrByte at hobbyretro.com telling me they had one available, so I bought it. And I’m pleasantly surprised ! It was cheap too, approx 30 Euros not including European shipping (another 6 euros). One of the reasons I was interested was because of the built in RAM test ability.

Dandanator CPC Features

  • 512kb of instant flash access memory. Immediately load both 128kb / 48kb / ROM programs and games
  • Selection via a menu in the Amstrad CPC
  • Cartridge Programming via USB
  • The programming software incorporates compression to the cartridge, making the most of its capacity
  • Operation without jumpers or configuration
  • It is compatible with any Amstrad CPC 464, 664, 6128 and 464+ and 6128+ equipment with adapter
  • Supports images in SNA, CDT and DSK format
  • Allows you to select pokes from a WinApe compatible library or enter them manually in the rom management software
  • it is possible to “freeze” the splash screens at startup for our enjoyment
  • Offers software for creating, managing and transferring game romsets for Windows, MacOS and Linux
  • Games can be loaded directly from the PC without burning them to the cartridge
  • Dandanator CPC is supported in RetroVirtualMachine, CPCE, Arnold and  ZesarUX emulators
  • Test Rom by McLeod Ideafix
  • Public domain project

The device is nicely made (3D printed case) with three buttons. It’s got a 512KB flash access memory on the inside which you can flash with games. The red button resets the CPC.

The device plugs into the back of your CPC lying down, so doesn’t shake about. Once you connect power on the CPC, it’s instantly available.

You have 2 pages of games/stuff to scroll through and you can do that using the cursor keys on the Amstrad keyboard, awesome ! You can see the memory requirements of each game beside it (128 or 64k). I assume the P. is for Computer pokes.

When you find a game you want to run, press the corresponding number on the keyboard and it loads instantaneously. It’s a really cool concept. Fast, cool, awesome, and  I really love the fact that it comes preloaded with a selection of very cool games.

There is a USB connector on the side (mini-a) for loading games/data onto the ROM, but that’s for another blog post.

Testing RAM

I tried the RAM test by pressing R. It was that simple.

I also wanted to test RAM on my CPC 664, which has suspect dead ram, that computer was dead on arrival as you see here.

At first when I connected the Dandanator to the 664 nothing happened. So I wiggled it and the CPC came to life, or rather, showed the same square video.

Pressing R did nothing but that’s probably because my keyboard membrane is faulty, or there is some other issue yet to be discovered. The reset button does reset the 664 so at least something is happening here.

I posted about this on the CPC Wiki and Noel came to my rescue, basically you have to hold down the left black button while powering on the CPC and it’ll run the RAM test. And here’s the result, all RAM chips are duff except one  (D3)!

As per Noel, “Lowest one is D0, top one is D7, so if you look at the 664 schematics, you can then figure out which IC exactly has the problem.”

And MrByte himself responded with this info on Facebook “Hi Niall, you can press alternate ROM when turn on CPC. Alternate is left button

Below is a circuit board diagram of the DanDanator.

So let’s take a look at the schematics for the CPC.

http://www.cpcwiki.eu/index.php/Schematics

Here’s the one I need for the CPC 664.

and here’s the corresponding motherboard for the CPC 664

Amstrad CPC664 PCB Top

Well that’s it for this quick blog post, I hope it gives you some ideas about the Dandanator, I really look forward to learning more about the device. Speaking of which, take a look at the links below for more info about it (in Spanish, use Google Translate in Chrome to translate to your language).

You can see a Dandanator in action in Noel’s video here and he uses it to help determine faulty RAM (or broken traces) in his CPC 6128. Hopefully I won’t have such issues on my CPC 664.

 

 

 

 

Posted in Dandanator | Leave a comment

Connecting an Amstrad CPC 6128 to an external LCD

Introduction

I have 3 CTM 644 monitors in various states, all work but one is missing RED. However they take up so much space in my little retro corner, so I wanted to use an old LCD I had in storage and wanted to connect it up to my Amstrads. Getting it all working took some effort so I’ll describe it here.

The LCD

The LCD I used was an old Dell 1908FP, I just so happened to have one that was not in use (old tech) and I wanted to see if I could get it working with my Amstrad CPC 6128. You can find one of these old LCD’s here on Amazon (I searched for this link, the seller is nothing to do with me, but as you can see they are quite cheap). The lcd is suprisingly good quality even for it’s age, it can move vertically and rotate on it’s axis 90 degrees to aid with accessing the connectors. I connected a standard VGA cable from the LCD to the back of my HDMI converter box.

You can see the other end of the VGA cable plugged into a VGA to HDMI converter cable here which is in turn, plugged into the HDMI converter box.

The HDMI converter box

I found this converter (again, this is not my store, I actually bought it on WISH) which has multiple in/out connections and my goal was to use a retro-shack Scart Cable TV Lead to connect to this box and then covert it to HDMI/VGA.

The power supply

As I wanted to move one CTM 644 monitor out of the way, I needed to power the CPC and in this case that meant I needed a 12v line (for FDD) and the 5v line (for the CPC). I settled on this model which was recommended in one of the Amstrad Facebook groups.

The bigger of the two cables is 12V out and the smaller one is 5V.

The SCART Cable TV Video Lead

I actually purchased the SCART cable tv video lead cable over 2 years ago and it was still in its packaging, this came from Retro Computer Shack and their packaging, quality and documentation is excellent, very good product and reasonably priced.

After connecting everything up I was pleasantly surprised to see it working immediately. I was relieved !

It’s very readable on the LCD and feels nice to look at. Next I connected up the 12v line and tested the FDD, it works as you can see here (I loaded up Alex Higgins pool world).

So all in all I’m very pleased with my new setup, I’ve loads more space for my CPC’s and this gives me new possibilities !

 

Posted in CPC 6128, HDMI converter, Lacie 12v/5v power supply, LCD, VGA to HDMI | Leave a comment

Dead on arrival CPC 664

Introduction

I’m a sucker for these computers, here’s another 664 but this one is sadly dead.

It makes a distinct noise when connected to power (the FDD motor doesn’t stop) so there’s that. If I disconnect the 12v line then i see the red led is on and a blank square in the center of the monitor, according to CPC wiki forums it could be dead ram.

I’ve ordered some replacement ram and ram sockets from ebay, oh and a FDD drive belt, I’ll try and repair this 664 as it looks good (in my opinion). I already have a waiting keyboard membrane also as I’m sure it’s already faulty.

Here are some photos from the original advertisement on ebay. The original ad text is below.

Vintage Amstrad Cpc 664 Personal Computer
 
for parts or not working, Power on sold as is, No image,
There is a crack on the outside, see picture 10. Does not include the Monitor.

The serial number is very hard to make out, but i think it’s 461111 K32-53

Posted in CPC 664 | 1 Comment

Disassembling my old code part 8 – Processing HEX text in the left pane

Introduction

This is part 8 of a blog series I’m doing to catalog some of the programs I wrote back in 1988 on the Amstrad CPC 6128, starting with a disc sector editor I wrote called Disced. I’m doing this because I like doing it, it brings back memories of how I started my career with computers back in the 80’s, long before Internet (as we know it today) or mobile phones.

Previous parts (including this one) are listed below.

  • Disassembling my old code part 8 – Processing HEX text in the left pane (this part)
  • Disassembling my old code part 7 – Drawing rectangles
  • Disassembling my old code part 6 – Processing disc activities
  • Disassembling my old code part 5 – Get Shift key and set translate
  • Disassembling my old code part 4 – Set cursor position and disc cache
  • Disassembling my old code part 3 – Text operations
  • Disassembling my old code part 2 – Setting screen mode and using Soft 968
  • Disassembling my old code part 1 – Getting started with WinAPE

In part 7 we saw how code was used to draw rectangles to ‘frame’ the output on the screen, to make a very basic user interface (UI) for the user to work with, so let’s continue where we left off.

The next routine we need to decipher starts at line 13 with a call to label 92E6. So let’s see what it does.

And here is the routine in all it’s glory.

Straight away I can see lots of calls to firmware address &BB75 so let’s find out what that does. According to the Soft 968 firmware guide it’s for arranging the text cursor in a specific place before actually ‘writing’ text to screen.

To get a quick idea of what this routine (or function) does in its entirety, I removed the call completely from the machine code by replacing the three bytes with NOP codes (no-operation) and called the code again. The result was this.

So we can be fairly sure that this routine is used to populate text in and around the rectangle frames. I’ve put the call back. Based on this I’ll give this routine a label of Fill_text_in_rectangles.

Next, I decided to add the Amstrad firmware calls used in Disced to the top of the assembly, that way the code will become easier to read. For example call &bb75 will become call txt_set_cursor. I’ll try and convert each firmware call I can find in the assembly to it’s readable label over time.

and the routine now looks like this, so next I need to find out what call L937F does.

It looks to me like it reads the character (into the A register) that is pointed to at the address stored in HL, and they prints it to screen, and keeps looping until the last char = 0.

This looping until A=0 is what I suspected in part 3 here so it’s good to have it confirmed.

So here’s that small routine with some re-labeling and txt to make it more readable.

And back to the original routine we were dealing with, i need to point to the text strings it refers to. I can see the address is actually referring to the Press Control + H for Help or press ESC to Exit message.

So I’ve pointed the routine to that text string.

Next there are three calls to L939F. To save time figuring out what that routine does I simply hacked the live code and placed a &C9 (RET or return) as the first byte, that tells whatever called it to simply return and continue.

It was quite obvious after doing that, that that routine was for processing text (hex codes)  in the left rectangle. In the screenshot below, you can see as it skipped that routine it moved to the next routine which was to print the text in the right most rectangle, but as the first rectangle was never printed, the Ascii text ended up in the wrong place.

After looking through the code some more it’s not only processing the code in the left rectangle, it’s converting whatever it finds into HEX for outputting to screen using 4 RRCA commands (rotate 8 bits to the right, some sort of conversion).

If you look closely it’s also missing the track, sector and page numbers above and they’d be in hexadecimal too, so I think that function is all about converting the text output in the left rectangle to hex and then printing it.

So now the routine is starting to make sense… at least I hope so, there are two last calls I’m not what they do.

So, to find out what those two calls do, I’ll remove them totally and run the program. After doing so I could see it moving forward/back through the tracks and sectors but not updating the code on the screen.

Closer examination showed that the first call was simply setting the starting point (txt cursor) of the text to be printed in the left rectangle, the second call processed all the actual code into hexadecimal and printed it to screen.

So after a lot of testing and looking at the code I’m fairly sure about what this section does, and here it is.

Resources used in this blog post

Soft 968 – https://archive.org/details/SOFT968TheAmstrad6128FirmwareManual/page/n157/mode/2up?q=bb84

Z80 RRCA – http://z80-heaven.wikidot.com/instructions-set:rrca

see you in the next part !

cheers

niall

 

 

 

 

 

Posted in CPC 6128, Disassemble, Disced, WinApe, Z80 Machine code | Leave a comment

Another CPC 664 for the collection!

Introduction

Oops, I’ve done it again, gone and bought another CPC 664, this one certainly looks beautiful sitting right next to my trusty CPC 6128.

The colour looks to me like it was painted, that might explain the lack of a serial number underneath (perhaps). That said, it’s in lovely condition, feels like new. Even if this was painted I can’t see any evidence (other than the colour looking slightly blue) that it was painted, so clearly a very well done job.

If you look at my growing collection below it’s the the 664 just on top of the grey Schneider coloured 464.

How cool !

But I have to stop buying these computers, I’m running out of space (and money).

Posted in CPC 664 | Leave a comment

Using ROMs with a ROMBO Rombox

Introduction

When I started out learning how to program in Z80 machine code back in the late 1980’s, I purchased a Rombo Rombox which allowed me to plug in various ROM’s. These ROM’s contained code that could be called upon using piped commands such as |Protext or |Maxam.

As I said in an earlier post, unfortunately I lost my original CPC 6128 along with the Rombox, but this year I managed to get my hands on an old one and that’s what this blog post will cover.

The Rombo Rombox would plug into the back of the CPC and depending on which ROM’S were installed, gave you access to programing ability, printing, text editing and more. Having the software burned to ROM instead of on disc meant that you could access it instantly, and didn’t have to load from disc. Quick and easy !

In the below photo you can see my Rombox open, with 3 ROMs (Maxam, Protext, Proprint) to the side and a chip removal tool.

Also to note are the dip switches (white on blue) which are numbered 0-8. They correspond to the ROM slots on the rombox. There is another switch, to allow you to use higher ROM slots (for example on my CPC 6128 I use the high switch 8-15 setting, on the CPC 464 I use the low switch setting, 0-7).

Details of what those dip-switches and high/low ROM settings are on the reverse of the cover, shown below.

When the board is empty it will look something like this.

After adding 3 ROM’s, I adjusted the DIP switches to match the ROM’s position in the rombox, so you can see that switches 4,5 and 8 are ON.

Note: I spaced the ROM’s like this as it makes them easier to insert/remove with the chip removal tool.

At this point I can connect the Rombox to the back connector on the CPC 6128 and then power it on, if everything went well you should see the ROM’s printing some text to the screen to announce that they are working.

To access the Maxam ROM, I type |Maxam and it displays the built in options for that ROM.

If you can’t get your hands on an old Rombo rombox, you can use a modern alternative, such as this one I bought from Rob Scott. You can see a video of it here.

until next time,

adios.

 

Posted in MAXAM, ROMBO rombox, Z80 Machine code | Leave a comment

My retro corner

This is  a short post to show what my retro corner currently looks like. I’ve setup two small desks in a corner of my office and connected two CPC computers to CTM 644 monitors.

On the left is a CPC 464 with Schneider colours (all grey) and on the right, my trusty CPC 6128.

Underneath the CPC 6128 you can probably see a 464 with it’s back to us, in that section I’ve got several CPC’s.

  • 2x CPC 664
  • 2x  CPC 472
  • 2x CPC 464
  • 1x CPC 6128

You can’t see them as they are all bubble wrapped (aside from the 464), also in the photo below are 2 CPC 664 keyboard membranes (new), waiting until I need them.

On top of one of the desks and connected to the CPC 464 I have an original Rombo Rombox with some roms (Protext/Proprint), and a newer rombox with some other useful roms such as MAXAM (assembler/disassembler).

You can also make out a very dusty Multiface two from Romantic Robot.

On top of the 6128 monitor I’ve the CPC 6128 manual and a large joystick. It works fine but every time I power on the CPC it generates an X. The 6128 is currently running Disced.

well that’s my retro corner, I’ve lots more CPC related stuff underneath the tables (magazines, tapes, hardware) which I may blog about later, until then, cheers !

niall.

Posted in CPC 464, CPC 472, CPC 6128, CPC 664 | Leave a comment

Disassembling my old code part 7 – Drawing rectangles

Introduction

This is part 7 of a blog series I’m doing to catalog some of the programs I wrote back in 1988 on the Amstrad CPC 6128, starting with a disc sector editor I wrote called Disced. I’m doing this because I like doing it, it brings back memories of how I started my career with computers back in the 80’s, long before Internet (as we know it today) or mobile phones.

I’ve found that the more I spend time on this, the more it interests and fascinates me. I still can’t believe I was programming this stuff back in 1988 without any internet, and only using a few books, a MAXAM rom (containing a text editor and and assembler/disassembler), and lots of trial and error.

Previous parts (including this one) are listed below.

  • Disassembling my old code part 7 – Drawing rectangles (this part)
  • Disassembling my old code part 6 – Processing disc activities
  • Disassembling my old code part 5 – Get Shift key and set translate
  • Disassembling my old code part 4 – Set cursor position and disc cache
  • Disassembling my old code part 3 – Text operations
  • Disassembling my old code part 2 – Setting screen mode and using Soft 968
  • Disassembling my old code part 1 – Getting started with WinAPE

Another week has gone by and it’s time to look at where we are with Disced.  I try to spend a few hours a week just looking through the code, cleaning it up and finding out what a particular section does, before blogging about it.

The first few routines have been dealt with and soon we’ll get on to what looks like key press handling (probably in the next part, or soon after), but before that we’ve got a call to label 9293.

So let’s take a look at that routine. It’s quite lengthy and right now I’ve no idea what it does. I’ll need to determine what the firmware calls are in order to figure that out. There are two firmware calls used in this routine (function ?) and they are shown below.

  • &bbc0
  • &bbf9

So the first firmware call is to &bbc0 and Soft 968 tells us that it is called 64: GRA MOVE ABSOLUTE, to move (graphics) to an absolute position based on what is in the DE and HL registers. DE points to the X co-ordinate and HL points to the Y co-0rdinate.

It looks like this entire section is drawing the initial graphics (rectangular boxes around the left/right panes). But let’s dig deeper.

To verify this, I hacked the code and removed the call by replacing the machine code with 00 (NOP, or NO Operation bytes). And then I called Disced again (call &9000), and sure enough, there are no drawn lines !

This is much easier to see when I call the routine directly from the CPC. So now we know exactly what this routine (L9293) does.

But let’s look at it further to see what the other firmware call is used for, and why are there  so many PUSH and POP commands used in this routine.

The other firmware call used in this routine is &bbf9 or 83: GRA LINE RELATIVE.

So again the two 16 bit registers DE and HL are used to pass co-ordinates to this firmware call, and calling it corrupts the contents of those registers and others. But why all the PUSH/POP commands.

Normally, loading DE or HL with values uses 3 bytes, so LD HL,&0000 in source code becomes 21,00,00 in machine code. However, PUSH HL (save HL to the stack) uses one byte E5. That value stored in the stack is later retrieved with POP DE (again, one byte).

This is a neat trick to save coding space (bytes) and it also speeds things up, as less bytes to execute means it will be faster to execute.

To get a better understanding of which bit of the routine was used for drawing a particular  line, I modified the code to ‘move’ the starting point, and exited the routine after only two sections, the result was the left most pane had two lines which are obviously not in the right place, but that was just to see how changing certain values affected the output.

You can just barely make out the second line (vertical) starting at the top right corner of the left pane.

And after my discoveries today and edits here is the routine in all it’s glory.

Resources used in this part

 

 

Posted in Disassemble, Disced, MAXAM, notepad ++, WinApe, Z80 Machine code | 1 Comment

Disassembling my old code part 6 – Processing disc activities

Introduction

This is part 6 of a blog series I’m doing to catalog some of the programs I wrote back in 1988, starting with a disc sector editor I wrote called Disced. I’m doing this because I like doing it, it brings back memories of how I started my career with computers.

Previous parts (including this one) are listed below.

  • Disassembling my old code part 6 – Processing disc activities (this part)
  • Disassembling my old code part 5 – Get Shift key and set translate
  • Disassembling my old code part 4 – Set cursor position and disc cache
  • Disassembling my old code part 3 – Text operations
  • Disassembling my old code part 2 – Setting screen mode and using Soft 968
  • Disassembling my old code part 1 – Getting started with WinAPE

So it turns out the last part I did for some reason I didn’t save my edits to the assembly, doh. But luckily I had screenshots of the edits so it didn’t take long to fix. Let’s resume with the next call in the start of the program and that is call &9440.

And here’s the code before I’ve added comments or labels but with some tabbing to make it easier to read and in addition, I’ve removed a spurious label and excess characters, for example, the original source code was exported from WinAPE as CP &00FC but it should really be CP &FC and I did this by comparing the ‘real’ code in the left disassembly to the source code in notepad++.

So here’s a quick before

and after.

Now that that section is cleaned up, what does it actually do ? Well from the labels that are already present I guess it’s doing something with the cursor position, then calling a firmware function called &BB1B which is shown below. This firmware call is KM_READ_KEY.

Just glancing at this code routine, I couldn’t really figure it out so I completely NOP’d out the call, and restarted the program, after doing so I could see the moving from track to track and sector to sector was no longer working, so it’s clearly something to do with that functionality or initialization of it.

While hacking it I also discovered where the current track and current sector values are stored, so I added that info to the source code.

After making those discoveries I looked further into the routine and found it was calling &BCD4 which is a firmware call listed below. Notice how (if found) that the C register contains the ROM value of interest.

So armed with that knowledge I updated the source code…

And some more digging led me to this bit of info:

AMSDOS Hidden RSX Functions

 [C006h]  INIT             ;in/out: DE=LORAM, HL=HIRAM, CY=?
 chr(81h) MESSAGE_ON_OFF   ;in: A=flag(00h=on, >=01h=off) (R,I,C) ;out:A=old
 chr(82h) SET_DRIVE_SPEED  ;in: HL=ptr to 9 bytes
 chr(83h) SET_DISK_TYPE    ;in: A=type (0xh=IBM, 4xh=CPM, Cxh=DATA)
 chr(84h) READ_SECTOR      ;in: E=drv, D=trk, C=sec, HL=dest
 chr(85h) WRITE_SECTOR     ;in: E=drv, D=trk, C=sec, HL=src
 chr(86h) FORMAT_TRACK     ;in: E=drv, D=trk, C=sec1, HL=ptr to 9x4 byte
 chr(87h) SEEK_TRACK       ;in: E=drv, D=trk, out: cy=1=okay
 chr(88h) TEST_DRIVE       ;in: A=drv, out: cy=1=okay
 chr(89h) SET_RETRY_COUNT  ;in: A=retry count (default=10) (01h..(1)00h)

To test this I added breakpoints in WinAPE’s disassembler by right clicking in the disassembled code and choose toggle breakpoint and then I stepped through the code.

By doing this I could clearly see the use of &84 to READ_SECTOR and &85 to WRITE_SECTOR as in this example, notice how when I pressed CTRL+W (to write the sector) it placed &85 in the marked square, and that is to WRITE_SECTOR.

So now I know that this routine deals with the interpretation of reading and writing to the sectors/tracks, so for now I’ll label it as Process_disc_activities.

This leaves me with some labels that I’m still not sure what they are for but I’ll return to them in the next part. For now though, here’s the routine I’ve worked on in this blog post.

So that’s it for this part, see you next time !

cheers

niall

Recommended reading

Posted in Amstrad, breakpoint, Disassemble, Disced, notepad ++, WinApe, Z80 Machine code | 2 Comments