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.
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.
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.
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.
see you in the next part !