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

Disassembling my old code from 1988 – part 3

Posted on 10th October 2020 by anyweb

Introduction

This is part 3 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 <—- you are here
  • 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

So let’s get stuck in. I resumed where I left off in the last part and that was to continue converting the source code into meaningful blocks of code, so that means converting the ASCII to readable text and once done, modifying the labels pointing to those text blocks. I also hope to understand how those blocks of TEXT are formed in order to understand how the functions that print them to screen know where the beginning and end of a TEXT block occurs.

At the moment I’m doing this on my Surface Book 2, but it would probably make more sense to run this on my gaming computer downstairs in my office to avail of my 3 monitor setup, I might try that later.

In the screenshot below you can see the WinApe emulator running Disced, and in the left pane we have the disassembly showing the section I’m working on (Press F7 in WinAPE to disassemble), with the source code on top and the hexadecimal/ASCII representation of that code to the right of the lower left pane.

In the Lower right, you can just make out that I’ve got Notepad++ with my source code  that I exported in Part 1 and I’m slowly adding the text but more importantly including every space, and opcode that is listed.

Marking the end of a block of text

I’ve already noticed that two lines of text ended with a NOP (or NULL) code (&00). For example:

TEXT "Press Control + H for Help or Press ESC to Exit",&00

Hopefully this means I’ve found out how my TEXT writing functions are working within the program as those functions must know where the beginning and end of a text block is.

We already know that the start of the text blocks are referred to within the code as Labels, but that only marks the start of the text block, it doesn’t show where it ends.

Here you can see two of those NOP (or NULL) codes at the end of some TEXT blocks.

A slight scroll down through the code and I can see this pattern of ending TEXT blocks with NOP codes (or NULL) repeated, so I think I’m on to something here.

I also noticed that if  I want to see the text within the program on WinAPE that I have to close the disassembler and activate that page in Disced before going back to the disassembler, I guess this is because it freezes the program while disassembling.

If you look at the repeated blocks of code after some TEXT you’ll see

 &0d,&0a,&0a

This pattern signifies a carriage return (&0d) followed by two line feeds (&0a). I use this pattern or a similar pattern with just one line feed repeatedly throughout the text blocks.

&0d,&0a

This is to make the TEXT displayed on screen more readable (formatting the text).

This use of line feed and carriage returns to denote Newlines is explained here and is not Amstrad CPC specific. My next challenge was the character set of the Amstrad CPC in relation to up arrow, down arrow, left arrow and right arrow. These characters are listed in the following wiki.

https://en.wikipedia.org/wiki/Amstrad_CPC_character_set

But when I looked at CharMap in Windows 10 I didn’t see anything quite the same, so I instead added those special characters as byte codes in the TEXT blocks, like so.

Turn off text cursor

After reading that Amstrad Character MAP wiki page, I could see that the &02 code was used to turn off the text cursor, this makes sense as it was just after the the title text and before the graphics routines start on the front page of Disced, so I added a comment to that effect in my source code.

This brings back memories to me from when I coded it originally, I think that if you didn’t turn off the text cursor prior to drawing graphics (lines etc), that you’d see a flashing cursor move across the screen, I can experiment with this later on when I actually try to Assemble the finished source code (if I ever finish it :P).

The next oddity I found was the use of &07,&18 just before the last two (Y/N) prompts.

&07,&18

As you can see highlighted here…

So when I looked at the WIKI page it explains that those codes could be for BEEP and  to exchange the PEN and PAPER inks (reverse video effect).

So I tested it, and sure enough, when I press ESC in Disced it BEEPS and shows the text in reverse video ! as you can see here in the GIF (it won’t BEEP however, but trust me that’s what happened).

So I decided that was enough for this part ! here’s the final look at the source code I modified this morning.

Recommended reading

Please join me in Part 4 where we’ll no doubt learn more about the inner workings of Z80 machine code on a CPC.

Posted in Disassemble, Disced, WinApe, Z80 Machine code | 6 Comments

Disassembling my old code from 1988 – Part 2

Posted on 26th September 2020 by anyweb

Introduction

In Part 1 of this series of blog posts I showed you how I started disassembling one of my old programs that I wrote in Z80 Machine code way back in 1988, my end goal is to not only have the source code all clearly laid out and readable, but once it’s done, I want to edit it and re-release it with a 2020 date stamp (assuming I get it finished this year).

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 <—- you are here
  • 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

 

But it’s harder than I thought, just looking through the code I realize that in order to properly label things in the source code I’ll need to re-learn about Z80 Machine code and how assemblers (like MAXAM which is what I will use to compile it) deal with it, so I’ve started doing that.

For example, I needed to know that the Assembler can use directives in the source code to decide what to do with various data. So how did I find out about that, well there’s a great website called https://archive.org and in there you can search for many things, I searched for Amstrad Assembly

and that revealed quite a few hits, I selected a few of the books listed and found the following page *after searching for DEFB* in a book called Mastering Machine Code on your Amstrad 464 664 6128.

Armed with that knowledge I continued reviewing the disassembled code side by side with the source code and started filling in some data.

Such as the following block of code used for changing the mode to 2 and then setting the ram memory address to &C000.

In the screenshot below you can see the WinAPE debugger showing the block of code i’m interested in, and to the right you have the source code opened in the excellent notepad++ which I’m manually editing to add clarity.

In this very small block of code a few things are happening. First of all the block of code (I’m not sure what we call that yet) is marked with a label which contains some descriptive text and has a colon appended to the label name “:” e.g.

change_screen_mode:

directly after that label, you’ll see I’ve used a semi-colon “;” to allow me to type in clear text and add notes about what each line is doing.

change_screen_mode: ; change screen mode

These are comments to make it clear to me what is happening in certain areas of code.

The label allows you to add labels to blocks of code in your source code and the assembler will rewrite those labels as hard coded addresses when you compile the source code.

As I’m re-learning Z80 machine code and assembly language I need to also understand exactly what each block of code is doing in this program, it’s going to take a lot of time but I think it’ll be worth it (for me at least).

If I look at Soft 968 which describes the innards of  the Amstrad Firmware (you can see that book here) you’ll see exactly what the firmware address &BC0e does and what it needs to carry out the function.

So we can see what this firmware address does. What about the remaining instructions, well I can see that I’m loading the register A with a value of &C0, and then I jump (rather than call) to an address of &BC08.

Here’s what Soft 968 tells us about that firmware call.

 

How do I actually call my block of code ? It actually happens at the start of the program using a call label format.

Actually, the change_screen_mode: block of code has me confused as I don’t see how it’s returning back to the source call, there’s no RET statement, but maybe after changing to mode 2 and setting the memory address to C000 the jp doesn’t need a RET.

The data available online for Amstrad is truly impressive and I’m really enjoying re-learning about how this all works. So much so that I purchased an original Soft 968 from Jason Brooks (member of the Amstrad CPC 464 facebook group).

Next I moved on to starting to modify some of the text in the code, as you can see here.

And after chatting with Jason Brooks and Chris Perver in that facebook group, it seems I need to edit this section so it looks something like this, I do recall TEXT being used in Maxam so maybe this is how I did it originally. I won’t really know until I try to compile it later.

So as you can see the progress is slow but I have to relearn all of this while I’m doing it, and I want to be sure I understand everything.

Well that’s it for part 2, please join me in the part 3 and we’ll see how far I’m getting.

Recommended reading

Posted in Disassemble, Disced, MAXAM, WinApe, Z80 Machine code | 6 Comments