Connecting an Amstrad CPC to an external LCD

Posted on 26th January 2021 by anyweb

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 (Schneider / Amstrad Bloc Alimentation. Alimentation CPC464/CPC664/CPC6128) 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 | 7 Comments

Dead on arrival CPC 664

Posted on 12th January 2021 by anyweb

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

Posted on 4th December 2020 by anyweb

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.

Other parts of this series, including this one are listed below.

  • Disassembling my old code part 1 – Getting started with WinAPE
  • Disassembling my old code part 2 – Setting screen mode & Soft 968
  • Disassembling my old code part 3 – Text operations
  • Disassembling my old code part 4 – Set cursor position & disc cache
  • Disassembling my old code part 5 – Get Shift key and set translate
  • Disassembling my old code part 6 – Processing disc activities
  • Disassembling my old code part 7 – Drawing rectangles
  • Disassembling my old code part 8 – Processing HEX in the left pane <—- you are here

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 | 7 Comments

Another CPC 664 for the collection!

Posted on 3rd December 2020 by anyweb

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

Posted on 27th November 2020 by anyweb

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

Posted on 26th November 2020 by anyweb

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 | 1 Comment

Disassembling my old code part 7 – Drawing rectangles

Posted on 14th November 2020 by anyweb

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.

Other parts of this series, including this one are listed below.

  • Disassembling my old code part 1 – Getting started with WinAPE
  • Disassembling my old code part 2 – Setting screen mode & Soft 968
  • Disassembling my old code part 3 – Text operations
  • Disassembling my old code part 4 – Set cursor position & disc cache
  • Disassembling my old code part 5 – Get Shift key and set translate
  • Disassembling my old code part 6 – Processing disc activities
  • Disassembling my old code part 7 – Drawing rectangles <—- you are here
  • Disassembling my old code part 8 – Processing HEX in the left pane

 

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

Posted on 9th November 2020 by anyweb

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.

Other parts of this series, including this one are listed below.

  • Disassembling my old code part 1 – Getting started with WinAPE
  • Disassembling my old code part 2 – Setting screen mode & Soft 968
  • Disassembling my old code part 3 – Text operations
  • Disassembling my old code part 4 – Set cursor position & disc cache
  • Disassembling my old code part 5 – Get Shift key and set translate
  • Disassembling my old code part 6 – Processing disc activities <—- you are here
  • Disassembling my old code part 7 – Drawing rectangles
  • Disassembling my old code part 8 – Processing HEX in the left pane

 

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 | 3 Comments

Disassembling my old code from 1988 – part 5

Posted on 31st October 2020 by anyweb

Introduction

This is part 5 of a blog series I’m doing to catalog some of the programs I wrote back in 1988. I’m doing this because I like doing it, it brings back memories of how I started my career with computers, and my first attempts at programming using Z80 machine code. I’m also trying to fully understand how I programmed Disced and I’m relearning how things work on the old Amstrad CPC 6128.

Other parts of this series, including this one are listed below.

  • Disassembling my old code part 1 – Getting started with WinAPE
  • Disassembling my old code part 2 – Setting screen mode & Soft 968
  • Disassembling my old code part 3 – Text operations
  • Disassembling my old code part 4 – Set cursor position & disc cache
  • Disassembling my old code part 5 – Get Shift key and set translate <—- you are here
  • Disassembling my old code part 6 – Processing disc activities
  • Disassembling my old code part 7 – Drawing rectangles
  • Disassembling my old code part 8 – Processing HEX in the left pane

 

So let’s resume where we left off, and that was going through the initial calls at the start of the program. Call L9388 is the next call that we need to understand so let’s get stuck in.

And here’s the source code in focus for that label.

From what I can make out it’s loading the C register with a value of &001A (DEC 26), and then it increases C by 1, before storing the value of C in the A register and then compares it to &0048 (DEC 72) and if so return, if not true it will make a call to the &BB30 firmware routine called KM GET SHIFT (KM=Keyboard Manager).

Now I’ll be honest, at this point I’ve no idea why I’m doing this yet but obviously it’s some sort of key press check. It’ll probably become clear later in my investigations.

Ok back to the routine. After making the call to &BB30 it does some additional instructions.

It loads the value of the A register into B, then subtracts &0041 (DEC 65) and then subtracts &001A, before jumping to L938A if C is reset, if not, it loads the C register into A and then calls the firmware &BB27 which is KM SET TRANSLATE which translates what a key should be if CTRL or SHIFT are not pressed at the same time. It then jumps back to L938A.

So based on the above, I’ll assume that this routine is for checking whether shift/ctrl are being pressed and name the routine accordingly, I can always change it later as necessary.

So here’s that routine all updated with new labels.

Resources used in this post

That’s it for this part, see you again soon in the next part !

cheers

niall

 

Posted in Disassemble, Disced, notepad ++, WinApe, Z80 Machine code | 7 Comments

Disassembling my old code from 1988 – part 4

Posted on 25th October 2020 by anyweb

Introduction

This is part 4 of a blog series I’m doing to catalog my adventures through some of the programs I wrote back in 1988.

Other parts of this series, including this one are listed below.

  • Disassembling my old code part 1 – Getting started with WinAPE
  • Disassembling my old code part 2 – Setting screen mode & Soft 968
  • Disassembling my old code part 3 – Text operations
  • Disassembling my old code part 4 – Set cursor position & disc cache <—- you are here
  • Disassembling my old code part 5 – Get Shift key and set translate
  • Disassembling my old code part 6 – Processing disc activities
  • Disassembling my old code part 7 – Drawing rectangles
  • Disassembling my old code part 8 – Processing HEX in the left pane

 

I decided that I wanted to start clearing up the beginning part of the code and make sense of the early calls that appear right at the start of the code. So that’s where today’s part begins, on the second call to label L941A.

I don’t yet know what this code does but let’s dig into it.

Here’s the source code in question for this particular label, it’s merely loading the HL register with an address &0605 and then loading that into another address at label &9626.

It then merges into another block of code which utilizes two firmware addresses namely:

  • BE66
  • BE78

So maybe those two firmware addresses will give me some clues as to what is happening here.

And indeed, those two addresses are important, &BE66 is for disc retries (default &10) and & BE78 is for disc error message flag (&00=on; &FF=off – reversed again) as you can see from this Amstrad CPC Firmware Guide.

So I’ve now added those comments from above into the functions (routines ? not sure what they are called in assembly) and hopefully MAXAM won’t complain about the way I’ve added these comments when I eventually try and reassemble this code.

This little code block (which is made up of two blocks of code) therefore seems to disable disc error messages and set’s the disc retries to 5 (I think).

I’m just not exactly sure why I’m loading HL with &0605 and then storing that value at L9626 before it actually sets the retry and disc error message status.

Let’s take a closer look at L9626. Doing so reveals the values &05 &06 which came from the value stored in HL above. So we can assume that these two bytes of data are important in relation to Disc bios actions, so I’ll assign this L9626 a label called DISC_BIOS_DATA: as I don’t yet know what the &05 &06 values are for.

I’ll populate those two bytes in the assembly source code with blank values (&00) seeing as we’ll be poking &05 &06 into them later anyway.

So they now look like this.

And next I use notepad++’s search and replace functionality to replace all instances of L9626 with the new label.

After those edits, I can see our wee block of code now looks like this.

And what’s clear here is that there are a few more areas used for temporary data storage, so for now i’ll just keep using the DISC_BIOS_DATA label but increment it by 1 each time I think it’s relevant, remembering that I’ll probably change a lot of these labels later on once I get it actually running.

I also replaced all references to L9628 with DISC_RELATED_FUNCTION as I see I used before calling &BCD4 later in the code, and that firmware call is to find a ROM command.

As these blocks of code are called right at the beginning of the program I’ll label them DISC_INIT_X, so here’s how it looks now.

and the very start of Disced looks like this now.

Update !

I had the WinAPE disassembler still open after submitting this blog post and I assumed I was done for the day, but the &05 &06 values still had me curious, so I decided to play around with them, hacking the values just like back in the day to see if I could figure what they were for.

And what I found was interesting, here’s what Disced looks like normally.

Notice how the moveable cursor is sitting in the Hexadecimal window pane on the left, and positioned on the first character there. I then changed &05 and replaced it with &01, to see what would happen.

then I closed that window (the disassembler view) and went back to Disced. Nothing changed, so I pressed Ctrl + Up arrow in Disced and it browsed to the next track, at that point it updated the UI and I could see a change, the cursor had moved up !

So that got me excited, I next changed the value to something bigger, like &08 and lo and behold it has moved the cursor down.

So at this point I’m certain that the &05 value tells Disced where to put our moveable cursor in relation to the X axis.

But what about the other value (&06). I reset &08 back to &05 and changed &06 to &00, and look at the result of that change !

So armed with that knowledge, I now know that the &05 &06 values are for defining exactly where I want the cursor to appear in my program !

I modified the Source Code to correspond to that new knowledge. After doing that, I set about hacking the other HL value of &88 &00, and I discovered that that address is where the contents of the disc being read are cached in memory, and any edits are stored in the cache and not directly on the disc.

Disced allows you to do it this way, you actually have to commit the changes in memory to the discs sector using CTRL+W. This saves you from destroying data on discs accidentally.

Awesome ! So after modifying the source code with my new found knowledge the little block of code now looks like this.

That’s it for this part, see you in Part 5.

Recommended reading

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