 I have a new package. Let's open it up and see what it is. This is a brother super power note, as you can tell. Laptop, it is a deeply weird device and I've been looking for one for a long time. This is actually a donation, shipped all the way to me from the United States. So thank you very much. I've been wanting one of these for ages. What this is, is it's one of brother's line of weird word processors, except in a laptop form factor. So this is not a PC. This has, as far as I know, got a Z80 processor in it. Despite that fact, it is actually a full-sized laptop. It's actually bigger than I was expecting with a decent size screen, although the form factor is a little bit weird. On this side, it has a floppy drive. On this side, it has, not a lot, but on the back, it's got serial and parallel ports, which is rare for these brother devices. It comes with a battery, which I'm not sure this has been used. I don't think it has. The way that all the packaging is still on it makes me think this might be an unused device. Yeah, that's never been opened. So let's take a look. It has been opened. The battery's been taken out and put back in again. It may be taken out of the bag. The bag's not sealed. So it is a 1,400 milliamp hour, six-volt nickel cadmium battery. Okay, we also have a floppy disk containing some useful stuff. This is a 1.4 megabyte disk. This will contain things that can be run on the laptop itself and some sample documents, as well as utilities to convert the laptop's documents into things that normal computers can read. And we have the manual, which is large and contains a special note regarding communication features. Well, good to know. Okay, the last remaining item is the power supply, which is a 120-volt US power supply producing nine-volt DC center negative. So that will be a thing that we need to remember. Center negative is unusual. These things are nearly always center positive. Let's open the lid. This looks like a, it's, ooh, yeah. That's a very weird keyboard. I don't think I like the feel of that. Let me pop a few keycaps. So I think it's almost certainly a rubber dome. It's a very odd rubber dome. It's a scissor switch. Okay, that is extremely peculiar. Never seen one of those before. I hope I haven't broken the key. So if I go to maximum zoom, you can see the scissor mechanism here. The key cap itself, put that the right way up. These pieces slot in here and then these clip on here. So there we go. It feels weirdly spongy. It's fairly tactile and the sound's not great. Yes, anyway, let's move on. It is covered with these stickers. There are three of them. So we have the perfect partner for PC owners, students, professionals, online users and those who don't know how to use a PC. Yes, so basically they're saying that they want everyone to buy one. And here, all the power you need built-in. The perfect partner for students, professionals and PC owners. To activate self-demo, press code D at main menu. On the right-hand side, three and a half inch, what, 1440K for a bedrive, 22 by 80 character LCD screen, which is one of the things that I wanted this for. Connects almost any type of printer. That's the printer port on the back. AC adapter, optional data fax modem. That will connect through the serial port. So this thing should have the ability to do basic internet-y things. What that probably means is that there is a serial terminal which allows you to dial up to shell access for some machine somewhere. But this is the battery compartment, which is very small by modern standards. Let's insert the battery. And now I have to figure out a way to actually get the camera to look at the screen. I have the secondary camera set up, as you can see. Let's turn it on and see what happens. The answer is very little. The battery is flat. So now I have to rig up a power supply. I can't use this because this is 120 volts and our European 240 volt electricity is just too strong and powerful for that thing to cope with. So I will be using my bench power supply. Bench power supply is hooked up. Power on. It thinks it's consuming 80 milliamps. It might be trying to charge the battery. So let's just remove that for now, I think. And the current drops off to nil. Yep, it's trying to charge the battery. Okay, power on. Very nice. Let me just fix the secondary camera to try and make that more visible. Filming this screen is excruciating. These old-fashioned LCDs are enormously hard to film. I am surrounded by light and I think it's more or less visible and in focus on the screen. I'll have to do some post-processing, but I think this is as good as it'll get. So I have charged the battery and installed a new button cell because the one that was in it was flat and found a small rubber thing that seems to have fallen off. So let me give you a quick tour through the software. What you're looking at here is the main menu. You can tell by the word main menu at the top of the screen. This shows you the main applications you can use. The primary one, of course, is the word processor. This looks exactly like the ones on my other brother word processors, which is good, because that suggests that the software stack is fairly similar. It's a... Let me try and type this correctly. It's an okay basic word processor. It's got stuff like character styles, layout, that kind of thing. It stores documents in memory, not on disk. You have to transfer on and off disk manually. It's got stuff like a layout preview. You can tell from looking at the screen that this is there for a bitmap screen, which is nice to know. Let me pull up a example program. Program, document. So I go to file, open file. It wants me to save this. So I press control D for not. This shows the documents that are in memory. We don't have any. I'm gonna load one of the samples of the floppy disk. So we press the menu button, load from disk. It looks at the floppy disk, like so. We pick one. Let's pick this... Let's pick intro, like so. It has now copied it into memory, where we can just open it. Now, this word processor is fine for small documents. You may notice I have my finger down on the key to scroll speed. Believe it or not, this is considerably faster than the other brother word processors. Still frustratingly slow. Trying to deal with anything big on this will be a fairly miserable experience. Let me just pull up the layout thing again. Nope, that's not working. Control layout. I've got the menu open. Control J. So this is giving you a better idea of the layout preview. Right. Now, I don't want to go into too much detail on the word processor because I'm not planning on using it. So let's just go back to the main menu with control menu. That actually takes us to the file menu. We then press file again, control file, to get back to the main menu. Right. Next application. Spreadsheet. The spreadsheet is different from the word processor. The spreadsheet can only open documents from the floppy disk, whereas the word processor cannot open documents from the floppy disk. The spreadsheet is not capable of dealing with in-memory documents. It's a fairly straightforward spreadsheet. One, two, three, four. So I enter some numbers, and then I can say at sum A1, A10. There we have the sum. If I change one of these numbers, it does not automatically update. Instead, you have to open the menu with the menu key. Data, recalc. Not the quickest. Let me open one of the samples. Abandon this document. Let's find compound. So that opens. Here we have a spreadsheet. It scrolls slightly slower than the word processor. I think it's a little bit more than one line per second. It depends how much is on the line that it's actually having to draw. So speedwise, not good, but I think it's doable. Anyway, that is the spreadsheet. Control file again to exit address book. Program 3. This is a very simple card file. I have entered some stuff. There is not a lot we can say about that. Calendar running along the top of the menu. It's a calendar. Not much you can really say about this, apart from the fact that I don't seem to be able to change month. Go to, here we go. So we should be able to go to now, which is November. Let me try that again. November tab. Right cursor. There we go. 2023. November 2023. It has a simple schedule system for times within each day, which I don't really care about. There you go. So file again. To-do list. It's a to-do list. Here is an item. I will now actually skip forward to file management. This shows the contents of the internal memory. So here, intro.wpt is the document that I copied off the floppy disk. That's the word processor document. We have databases for the schedule, the address book, the to-do list, and some settings for the communications software. You can use this to do disk-based stuff, you can do disk-unkey. You go to disk-disk-index. It thinks. And here we have the directory of things on the disk. And we can go to the menu and see the things you can do with it. Now, one thing that you cannot do with files on disk is open them. Instead, if it's a word processor file, you have to copy it into memory. If it's a spreadsheet, you have to go via the spreadsheet software. Anyway, let's look at the world clock, which is the most graphically impressive of the lot. It's a clock. So we should be able to... If I can remember how this works. Here we go. We can set the time. My local city is... Not that button. Time setting, local city. Here we go. Geneva. It is... Month is the 11th day. I think it's the 15th. 2023. Yes, it does actually... The entry is a bit weird. You can't just type 2034830. It's not working. Ah, ah. That's because I was trying to use 24-hour clock. Of course, now it's forgotten all the settings. I was trying to use 24-hour clock, and 20 is not valid until... I toggled not that one. That one. Right, now I should be able to type 2030. So the month is the 11th. Date is about the 15th. Year is 2023. Day month year. It doesn't have a year month day, only options you've got. And return. And it updates. And it even knows roughly where Geneva is. Back to the main menu. Program 4 is the fax machine. Now, I said earlier that this probably had a simple terminal. It does. That comes next. I don't know what the fax thing does. I don't have a fax number to fax it to. I presume that what it does is it prints out a document. But in order to fax it, it's going to have to do its own print layout and rendering. That is, it has to have built-in fonts. It would be really interesting to see what that looks like. But I can't do anything with this. Communication is a serial terminal. It's exactly what I thought it would be. It's designed for modems, which is why it's talking about phone numbers. But the board rate settings are respectable. 9600 is perfectly usable. 8n1 is standard. We don't want local echo. We do not want to do any of that. We now have a perfectly serviceable setup for hooking it up to a PC or Linux machine and doing remote work via a terminal, if you want to. Anyway, moving on we have the calculator. It's a calculator. It does say control Q to change 10 key mode on off. Ah, that allows me to use these extra numbers on the keyboard. Yeah, it's not a brilliant calculator. If I do that, plus one error. Numbers bigger than that don't exist. We have disk application, but let's go straight to setup. You can configure the printer. It supports a variety, a fairly small variety. But given the era of this machine, you're going to hook it up to a cheapo inkjet or dot matrix and print out text. So that's absolutely fine. You can password protect it. It has this really interesting quick charge feature. If I select that, it soft piles off. The current drawer suddenly shoots up to 200 milliamps. It seems to be dumping as much as possible into the battery as quickly as possible. So let's just turn that off. Current drawer drops to 60 milliamps. Back on again, main menu. Self demo is not exactly what I would call a demonstration. It's a few pages of text. That's it. You can print it, but you can't save it as a document, which would be possibly more useful. And the last thing is disk application. All text files in memory must be saved on disk before beginning. Let's just abandon those. Are you sure you want to delete? This has just done a full reset of everything in memory. Now looked at the floppy disk. This is the one application that is supplied. It's got this cool intro. So cool. So slow. So unskippable. It allows you to play turnabout, which is reversey. It's, what can I say, it's reversey. I have played one game against it. I won. This suggests that the AI in this is not really much good. So we go back to the main menu. Go to file management. And we see that our documents vanished. Have our other things vanished as well. Let's take a look at the address book. The address book is kept. I actually thought that would be deleted. And it's kept the calendar. And I presumably also kept the to-do list. Yes, it has. So that is a very quick tour of the software package on this thing, which I'm not going to be using. The thing I'm mostly interested in is the disk application. I have had software running on these brother word processors and the other models by reverse engineering the software applications and figuring out how they work. And because this comes with one on the floppy disk, this means I should be able to do the same thing here. Chances are that this thing has the same CPUs or the other brother word processors, which is great, because it's a Z80 compatible integrated device with lots of peripherals. It is well documented. So accessing the peripherals doesn't require what weird electronics brother has. It just uses all the standard built-in things. But I think at this point I want to turn the thing off, open it up, and see what there is inside. Here we are looking at the bottom of it. Let's undo the screws and see what happens. I have removed the battery. Well, that's interesting. The three screws have just removed the keyboard module, not the rest of the case. This does give us a decent look at the PCB. A Toshiba integrated chip of some description. A Z180 CPU. Yes, that is the same thing that the other brother word processors use. That is very good news. Some very nicely labeled chips here. So we have the 8 megabit mask ROM, an unpopulated additional mask ROM, 1 megabit of SRAM, 256K of SRAM. This is almost certainly the floppy disk connector. Let's remove these screws and go for the next layer. Right, now that's a interestingly bare board. Huge great suede with nothing on it, which is not a bad thing. Here is the LCD connector, parallel and serial. There's an interesting unpopulated footprint here. It says 8 megabit ROM. This is probably to allow certain models to use a 32 pin dip ROM instead of this. That could be useful for potentially replacing the ROM. I'm just looking at how much space there is under the keyboard. It would be nice to be able to put a socket in there, but of course it's hard to take this thing off and I don't think I want to do that. That should give me a nice 4K image of the layout of the bottom. I have looked up all the chips on this and everything is exactly what I expected. There are no surprises, which is a good thing. This is the Z180 CPU. That's an enhanced Z80 with stuff like memory management and a few extra instructions. This is a 1 megabyte ROM containing the system software. This is 128K of user RAM. This is 32K of additional RAM. This is probably video memory. This is a NEC 765 compatible floppy disk controller, which is great because these things are well understood and easy to drive. This is a comparator. I suspect that given the button cell is here, this has probably got to do with detecting the battery voltage and being able to tell the user when either battery is going flat. This is a real-time clock chip. Probably run of this 32kHz crystal. This, as I expected, is a level shifter for the serial port. It seems to be using plus and minus 16 volts. These are two hex inverters used for buffering the parallel port. That's basically all there is to it. It is not a complicated machine. I expect that all the custom logic for stuff like the LCD controller device selection and so on is baked into this gate array. I haven't been able to get any information on what this is, which is perfectly normal for gate arrays as they will be programmed by Toshiba for this application. So we're just going to have to guess at that. So what is next? Well, normally the next stage for a project like this is to read the ROM. However, while my soldering skills are probably capable of taking this thing off the board, they are not capable of putting it back on the board, and I don't have a socket for reading this anyway. So we're going to have to skip that step. So the next place is to take a look at the floppy disk and pick apart the turnabout game, the reverse C port, in the Ghidra reverse engineering tool and see what we can see. Here we are looking at Ghidra. I have loaded the turnabout program into it, and it's made a start at decompiling it. I have also gone through and done some picking apart. The overall structure is pretty obvious. The stuff at the beginning here looks like a magic number of some kind, a header, because it doesn't seem to produce meaningful machine code. The entry point is, I believe, here where it actually starts doing stuff. We can see there are system calls here. This is calling one of the Z80 system calls, which is a nice, cheap one-byte instruction. The good news is that these all look just like the other brother devices. So this is the same operating system that they run. It will be a variation. I'm sure the system call numbers won't be quite the same, but it looks very similar. Reset 6 appears to be high-level stuff. Reset 5 is low-level disk. Reset 1 appears to be used for the keyboard. If we look here, we can see it making a reset 1 call with A is 5, and then it checks it against lots of suspiciously suspicious numbers. I think this is the keyboard handler. So it's reading a key and then doing something based on the result. And down here, it just loops back to the top again, so it just keeps doing this until something happens. Over on the right here, Gidra has made a reasonable attempt to try and decompile it into C. It hasn't worked very well. But there's more we can get from this. For example, if we hunt around, I think it's down here somewhere, it should be able to find this is probably data tables. It doesn't seem to be machine code. If I disassemble this, it looks like machine code, but nothing quite makes sense. Like there's a pop here with no push. It could be popping the return address, but it wouldn't be doing that into AF. So I think this is not machine code. I think that's data. ASCII text, quite a lot of ASCII text. These are all the messages the game uses. And this is really useful because we can find, for example, here, Machine2Man is asking how many players there are. 8F5-4. So we search memory for 8F5-4, search all. Hey, look, it's found a couple of entries. So we go there, and it is loading the address of the string and then calling a subroutine. Pretty obviously, that is printing the string. Therefore, I've called this print string. If we follow this and look at the code, we can see the incoming data is in DE, and here it reads a byte and then does something based on the value. And FF is at the end of every string. So pretty clearly, FF is the terminator and look, the code does indeed jump to RET when it sees an FF. So yeah, this is, I believe, printing a string. And it works by looking for any subroutines it's calling. I don't actually see one. It does appear to be copying the character into whatever pointed that in HL, this which is red from here. So maybe it's not actually putting it directly onto the screen. It could well be copying it into a buffer at this address. Anyway, this is how you figure out what stuff's doing. But there is more we can do. Over here is GIMP. If we load up the, we want all files, turn about to APL, turn off select file type, and we want to find raw image data, which is here. This will then produce this dialogue. And this is going to interpret the image data as binary. Unfortunately, I have a high DPI screen and it's not a very big file. So for RGB, it's this little blob of gray up there. Unfortunately, I can't actually zoom in, which is irritating. But if we change this to black and white one bit, you see there's more, you can see some structure. The horizontal banding indicates stuff. At the top, this white noise is machine code. So these are obviously data tables. And now the easiest way to find like characters is we change the width to say eight. And now we have, we want to change the height to something big. Seven, nine, one, six is the maximum. So here it is in this band down the side of the screen. And all you do is you scroll down until you see these. These look like characters. In fact, this is not, ah, there we go. So these are clearly used to find characters and are used to in drawing, you know, text and stuff. And we can figure out where these are. This is at Y address 5550. And 5550 is 15AE in hex. The program loads at 800. Therefore, 15AE is 958E. Yeah, I actually had this already in there. Problem with swing and every now and again this dialogue pops to the top. But anyway, here, these are a set of 32 user defined characters. But there's more to find in the binary. So let's go back to GIMP, go back to open, turn about to APL. We want again, we want raw image data. Select the file again. Okay. Now difficult to see, probably easier to see in this. This is eight pixels wide, so each horizontal rows a byte. But down the bottom, there's this stuff. This all looks very suspiciously suspicious. So I think that may be a bit map. So we go over to GIMP. We scroll down to the bottom, and we start increasing the width. As we increase the width, the height, of course, gets smaller. We can deal with this by bumping up the offset so that the bit we're interested in, there we go, is at the top of the file. Okay, so we keep increasing the width. You see the data here is going a bit weird. Keep going, and eventually, you start seeing some structure. It says brother. We have just found the bitmap used for drawing the title screen. And below it, with width of slightly more, is the turn about logo. So we can locate those in the binary. And these are somewhere, there we go. Brother, logo data, and brother, and turn about logo data, which I found earlier. So this is at 9bd4, search memory, 9bd4, search all here. And here is a routine. This is loading the address of the logo and doing a thing. There is, in fact, a loop here, djnz decrements b, which has been set up here to 2e. So this is doing something on a loop. Given what we see when the program runs, that animated logo, I think it's pretty clear that this is the loop that draws the animated logo. And then a bit further down, we see exactly the same code again for the turn about logo. And a here actually turns out to be the width of the binary in bytes. So this is 16 horizontal bytes, 16 by 8 is the 128 that we saw. And this is the 132 that we saw. So I think that these routines are doing the draw. So this is our splash screen stuff. And then it drops off the bottom and does a thing and then exits. So this routine here is going to be the thing that draws the splash screen. That is called from 9873. It's just up here. And this is called from a routine that is right at the top of the file just after the initial setup. So this is, I believe, the init and splash screen code. One interesting thing is the whole stuff has happened with interrupts turned off. There's a DI here and an EI here. So I don't know what that's about. It's also doing stuff with ports. Anyway, this gives us a place that we can start picking away at the code. So down here we have these two routines. They've got something to do with drawing the logo. Follow that through. This is doing some math. There's a multiply there that said 180 has a hardware multiply, although it's only 8 by 8 bits. So I think this is probably preparing something. So the only other thing here that's doing work is this one, a 9935. Yeah, this is doing a lot of stuff. So I think this is the thing that's actually doing the transformation and blitting the logo onto the screen. So by following through this stuff, we should be able to find out how things are getting onto the screen. But let's not get ahead of ourselves. Let's try something nice and simple. Here's our init code. Here is the show splash screen. That is at 1873 in the file. So we go into the appropriate directory, copy the program as an examples disk. This is the copy of the two floppies. So test dot APL. Load it up in a simple hex editor. We want to go to 1873 and we see CD 7898, which is exactly the same as what we got down here. So let's turn these into knobs. And a knob instruction on this A80 is, I'm not quite sure, but let me go look it up. Okay, 00, 00, 00. We have just stubbed out the call to show splash screen. So save, quit. And now let's put test APL onto a floppy disk and see what happens if we run it on the machine. All right, here we have floppy disk. Insert into the machine. Here reads the disk. Test the APL. Now let's see what happens when we run it. Game starts. No splash screen. We are successfully running a modified version of the binary. This means the binary is not using any kind of checksumming. We can just put random bytes of code in there and it will execute it. This gives us the first thing we need to completely open up this thing, the ability to run arbitrary code. Plus, of course, it is now much easier to play games of turnabout. So what do we do next? Well, the next thing I need to do is to do some more picking away. I need to find the minimum program I can run. I don't know what any of that header is. I don't know how much of it is necessary. But once I have the ability to build my own machine code programs and turn them into something runnable, I can then start running real code. I can either poke away at the system calls and try to decipher them, or, and I think I would prefer to do this, go look up the Z180 documentation and figure out how to talk to the serial port and see if I can emit bytes there. Because I want to get a ROM dump because the ROM will tell me stuff like where in memory the floppy disk controller is, useful stuff like that. And if I can run arbitrary code, then all I need to do is turn interrupts off and I have complete control over the machine. So simply paging through the ROM a bit at a time, squirting it out over the serial port, should give me a easy ROM dump. I will go and do that then. I have good news and bad news. The good news is I figured out the binary format, which is completely unsurprising. And I've also located the screen in memory. So I can run this program and stuff appears on the screen. The screen is in fact not bit mapped. It is a character cell screen, which is great for me because it's really easy to use. Write a byte, receive a character. However, the bad news is I haven't been able to figure out the serial port. I have actually traced the tracks inside. And the serial port's level shifter here is not connected to the UARTs on the processor. Instead, it's connected to this glue chip, which makes me think that either there's a custom UART in here somewhere or else you need to do some port shuffling in order to root the UART signals from the glue chip to the Z180. And I don't know how that works. So the serial port is out. This is a problem because I need a ROM dump. I need to be able to reverse engineer the ROM dump to find where things are in memory. There are alternatives. One alternative is to try and save the ROM onto floppy. I do know the system calls used to read and write to the floppy disk. Unfortunately, on this platform they don't work. I can only assume great. So how am I going to get a ROM dump? I need the ROM dump in order to do things like locate the keyboard, find out where things are in physical memory, et cetera, et cetera. Well, there are two things I can do. One of which is that because I can write on the screen, I can simply display the ROM a few bytes at a time and then use machine vision to read the data off the screen from the video that I'm recording right now. I don't want to do that. That sounds like work. The alternative is to try and locate the floppy controller and find out where its IO ports are. There is actually something we can do here because the floppy controller is an external device and it's well documented, I know where the chip select line is. It's the fourth from the bottom on this side. So if I write a program that fiddles with all the IO ports and then monitor the chip select line, then when I hit the IO port that's mapped to the floppy controller, I should see the chip select line move. So I've written a program to do that, which is what is currently running. I need to do a bit of hardware setup including getting out the logic probe, but let's give this a try and see what happens. Here we go. I touch the logic probe to the relevant pin. There is activity. It is mostly high because this is a active low signal. I run the program and you see the lights flashing because there's activity. Looking at the screen, which is hopefully visible, that's made it worse. There we go. This is currently looking at port 40. So all I need to do is to push this button and work up through all the ports until I see one where something happened. This is reading from the port so it shouldn't like accidentally write to the disk, but we should see activity on the logic probe. Well, that didn't work. My guess is that the chip select line is being held low to do the read too briefly for the logic probe to be able to identify it. So I'm going to need an oscilloscope to figure this one out, I think. I got no joy with the oscilloscope, but I did have a thought. And instead of using the chip select line, if I probe the read line, which is that one, I get something different. So the light is blinking because the operating system is pulling the floppy drive to see whether there's a disk in it. If I start the program, you can see the flickering as it tries to load it. I can then slowly, oops, I missed past it. I can find that, there we go, light on, light off. IO addresses from 80 to 87 are mapped to the floppy drive controller. Normally I would expect the chip select line to be gated by logic in the glue chip. It's using the read and write lines to enable and disable the chip, which is kind of backwards to the way I was expecting. But anyway, we have found it. Light off, light on, light off, light on. That is our IO port. So with this information, I already have a 765 driver. So I should just be able to configure the 765 driver for that port. And we get floppy drive access. Of course, this all very much depends on, you know, whether it actually works. I was unable to make the floppy disk drive work. I found the floppy disk drive controller. I was capable of sending it commands. I could see it execute the commands. I could make the drive seek backwards and forwards, turn the motor on and off, stuff like that. But when I tried to do a read or a write, no data came through. There's something else that needs setting up. It's probably to do with DMA. I need to look at the ROM to figure out what this is. So I need to do something different. That's possibly a bit drastic. The Z180 CPU on this thing has a 20-bit address bus. I have soldered this yellow wire to A19. That is, as far as I know, otherwise unused. This black wire is ground. You can see on the rather dodgy oscilloscope picture, this is just like random noise. If I run my program, we get this. And if I press the single step button, we can see pulses. One, two, three. This is done by simply doing memory reads of a very high address. This causes the address line to pulse. We get signal. So I can now write a program that will work through ROM and generate pulses based on the bits it sees. Then I can hook it all up to my logic analyzer, capture the result, do some post-processing, and I should have a working ROM. You shouldn't normally have to do this. So let's give that a try. One and a half hours later, I have this capture and pulse view. As has already been established, if you've been watching my videos, I do not do well with numbers. And as a result, I actually managed to capture 16 times as much data as I needed. So there's actually 16 megabytes worth of data here rather than the one megabyte of the actual ROM. So it shouldn't really have taken this long. Nevertheless, here is the data. Nice groups of eight pulses. That's a 11110011. So all I need to do now is decode this and produce actual numbers. There is one interesting feature. Because we're using the higher address line to signal, if I'm actually reading a byte that uses that higher address line, you get this extra pulse here, which is where the byte is actually read into memory, and then it's emitted as eight pulses. So there are, in fact, nine pulses here. One, two, three, four, five, six, seven, eight, nine. Yes, that is nine. So my decoder just has to be careful to, you know, cope with this. It just needs the last nine bits of any number. So the next piece of action is to write a decoder, which isn't going to be very hard. Getting the data out is easy enough. There's a useful format called value change data that basically gives me the times between edges so that I can find all the places where there's a leading edge and it will give me the time from that to the previous leading edge. So, you know, I just walk through the data looking for short intervals, which indicates a bit, or a long interval, which indicates a byte. And then I should have it. Let me give that a try then and see what happens. After quite a lot of decoding work, I now have a one megabyte ROM here loaded into Gidra. And I have been spending some time slowly picking away at it and discovering its secrets, which honestly takes forever. The ROM is big and very complicated. These brother ROMs have this absurd banking system with huge piles of routines down in low memory here that set up memory management registers so that you can call them, et cetera, et cetera. But anyway, I have figured a bunch of stuff out. I've found out where the floppy drive controller code is, which is useful. The serial port, which is useful. The keyboard controller, which is also useful. And I've also discovered a huge number of weird and wonderful IOPorts so I don't know what they do, which is less useful. But let me find the floppy code for you. And there are in fact a few interesting things. If I search for the KIOFS string, it takes me to here, there is this string in the floppy code. So if Keo happens to be watching this, hi there, please get in touch. Anyway, I have figured out how to talk to the floppy controller. And it is, well, they have done some seriously weird things to this poor floppy chip. It seems to be connected via the glue chip in peculiar ways. So here is the code that just simply writes a byte to the floppy controller. This is for a command byte. And what it does is it checks some bits in the floppy status register to indicate the previous command is finished. And then as my code gone, wait for the previous command to finish. Wait until the floppy controller is ready to receive a byte. Output the byte. So far, so normal. And we can follow through to the IO area. Here are the normal two registers that 765 floppy controllers have. But there's also a lot of work being done elsewhere. Now, the operations register here is documented. It's part of this particular floppy controller chip. But then there's other weird stuff like this port. This port is used by the DMA code. This is the code that actually does the transfer to and from the floppy controller to actually transfer data. And it uses the Z180's DMA engine. It's easier to see over here in the decompiled source. We set up the port to read from. We set up the physical memory address to write to. We set up the length. But it's reading from this port 86, which doesn't seem to be documented anywhere. It's not part of the normal controller. So I don't know where that's coming from. It seems to work. And there's more stuff. So if we go all the way down here to port A8, there's this miscellaneous port. Here's a relevant piece of code. Before it does anything with a command, it will wait for something in port A8. Which is done by this helper function here. The bottom three bits appear to be whether a disk has been inserted into the drive. The index pulse itself and this bit four, which has the previous floppy command finished. And I don't know where this is coming from. The pinout on the floppy controller it's using doesn't have anything like this. So the only thing I can think of is that reading from this port is causing the glue chip to do reads from the floppy controller or something. I don't know. It's all kind of strange. This is not normal. The other brother word processors I've dealt with with 765 controllers have just done everything the normal way. But anyway, I have slowly figured out how it all works and I've written some code. And now as I'm about to demonstrate, I can read stuff of floppy disk. So my test program is on this disk. So the disk, I get the directory, I run it and it works. Now it doesn't look like much, but what this has done is performed a drive seek, a read, the first two zero zeros indicate that the command has executed successfully and the stream of hex underneath it is the data that it's read from the floppy disk. So this means I can read from the floppy disk and if I can read, I can probably write unless there's some weird gotcha here. So this means that the difficult bit, which is access to the drive is done. I mean, I need to like bolt it all into the actual code for the CPM ish kernel, but it works. The next thing, in fact, the only other thing I need to do to make this work is to decipher the keyboard and that shouldn't be that hard. I found the code in Gitra. So let me go back to the desktop. So here is how it works. The logic is a little bit contorted because it does things in a slightly odd order. But basically, here, it energizes a particular column. Here, it senses a particular row. Now, the reason why the sense happens before the energize is so that it waits until the next time scan keyboard is executed before it actually reads the data out. And in fact, there's more to it than that because this bit of code here only ever does the scan every other call to scan keyboard. I'm not sure why it's doing this. It could well be that it takes time for the glue chip's logic to update. Normally, when you probe a keyboard, you just set the column and immediately read out the sense data. But if there's buffering in the glue chip, it may take time. When it gets down to here, it has the sense data and the value of keyboard current column represents the column that caused that sense data. So this annoying piece of code here is just multiplying the column by 10 and then adding on hex 2000. This gets a pointer to the keyboard state table, which is here of 88 bytes, probably. Then it works through the sense data a bit at a time looking to see whether the key is pressed or released. And then these relevant bits of code, which as you can see I haven't gone through in as much detail, will update a bitmap somewhere based on whether the key has gone up or down. So that's actually pretty straightforward to duplicate. So I am going to try this and see what happens. And here is the keyboard handler. The numbers you are seeing are keyboard scan codes. They're just kind of arbitrary. They don't match what the brother OS uses. I have to go and map the keyboard and build a translation table. The first code of any pair is for key down. The second code has the high bit set. That's an A5 and indicates key up. And yes, it does do multiple key presses at once. I don't know how much roll over it's got. We'll find that out later. But it all works. I mean, this is just producing scan codes. It then needs an actual keyboard ring buffer, just like the brother OS had. But I'll deal with that when I actually come to do the real code. Which is what comes next. We have everything we need. I can access the floppy drive. Contact the screen. I can work the keyboard. Stuff like the serial port will happen later. But I think I have enough here, almost, to do my CPM port. The almost is that I don't actually know where the RAM is in physical memory. I know that my program here is running out of it. But I need to go and find where it actually is. I need to map all the physical memory into virtual memory so that the Z80C64K of actual RAM and just ignore the ROM. But that will be easy. It just needs poking addresses and seeing whether they change or not. So I won't bother doing that on camera. So, next step. Work on the CPM BIOS. About a week later. And after having had a cold, which is probably making my voice sound funny. Here we are. If I just fire it up, load the disk menu. Put the disk in the drive first, of course. And here we are. It was surprisingly easy to port. The hardest part of the whole process was figuring out the floppy drive controller. It's subtly different from other 765-based floppy drives that I've dealt with before. These things are always a pain, but I did eventually make it work. And I think there's some stuff I can do to fix the generic code that CPM uses. But anyway, it turns out that these high-density disks can store 18K on a single cylinder. That is, without having to move the head. That's 9K on a side, which, by CPM standards, is really good. And I have used the extra 64K of RAM that these things have over the top of the main 64K that CPM uses for a massive track-sized disk buffer. So when it reads and writes data, it just reads and writes entire tracks at once. Which means that it can read 8K of data in a single revolution of the disk, which is incredibly fast for CPM. And this means that programs load and run really quickly. It's a very nice machine to use. So if I, for example, fire up BBCBasic. There we go. I can look at the top of memory. That's decimal. Put that into hex. E900. Bottom of memory is, of course, zero. I can put that into kilobytes. 58K. 58 and a quarter K. Which is very respectable by CPM standards. I could use the extra unused memory to page the BIOS, but it's probably not really worth the hassle. CPM 3 will try to page out the BDOS itself, but CPM 3 is annoyingly difficult to port. And I generally think that there's no real benefit to it. So what do we have on this? Well, there's the standard software you get with CPM-ish, including the QE text editor that I wrote. This is a VI adjacent screen-based text editor. It's, you know, just a text editor. It works really nicely on this. I do need to implement repeat key on the keyboard, which I haven't done. So we'll just exit out of that. You've got the standard assembler, ASM. Oh, yeah, this I also wrote. It's not very good. You've also got ASM 80, which is not mine. I don't actually have any sample assembler programs on this machine, unfortunately, so I can't demonstrate these. You've got the usual tools like submit, copy, hex dump. It's a hex dumper. In terms of programming languages, you saw BBC basic. We've also got camel 80, which is a fourth interpreter. So let me see. Two five star dot tells us two times five is ten, which I assume it is. We have the Z8E debugger, which is a screen debugger. There we go. If I, again, this is now single stepping into BBC basic. I did actually use this to debug a problem I discovered in CPM-ish. What it's trying, what it's doing now is clearing memory. If you, it's writing zeros into HL. You can see the value of HL at the top of the screen changing. I hope that's legible. This screen is impossible to film clearly. Anyway, exit out of that. I also put on turbo Pascal. Yes, we do on error messages. Okay, let's write a program in Pascal. Edit test dot pans. Okay. Program test begin. Right. Hello world. End with a dot. Okay. Ctrl KD to get back to the prompt. Now can do R. That just runs it. It compiles it into memory and then runs it. Or we can go to options. Change it to compile to a com file. Now we do quit out of options. See to compile and we're done. Quit. Save our program. So we now have a test dot com and test dot PaaS. Test dot PaaS is of course our program. And there we go. It works. That test dot com is pretty big. That's 10 K for hello world because it contains the turbo Pascal runtime library. And that shows you just how much of the disk we have used. We still have a megabyte free despite having loads of stuff on it. And I can load up test dot PaaS in QE. No, it's a text editor and text files. So this machine has I believe a six megahertz processor, which puts it about 50% faster than most Z80 systems of the day. They were usually around three or four megahertz. So in fact, this is a really nice thing to use. It's the nicest CPM laptop I've ever come across. Oh yeah. And then I also found a nice feature in the video circuitry by setting a bit in one of the video ports. It changes from the 80 by 22 text mode that it was previously using to 80 by 25, which is the sacred size of terminal that all CPM software assumes you have. So this is really good. Everything will run on this. For example, the pinnacle of CPM gaming is ladder, which is a platformer. So I am the P and the Q at the bottom of the screen. I can jump. I can climb. Whoops. I hit one of the O's and died. I need to climb the ladder. Turn left. Jump over the hole. Oh, there was an O lurking there. Let's try that again. Okay, I'm not exactly very good at this. I got to level two when I was testing this earlier. This gets around the inability to test whether a key is pressed by... There we go. Level two. You press one key at a time in advance of any direction change you want to make, and then you just keep going. So press right, jump, jump. I hit that O in midair. That is unsporting. So despite the fact that it looks like somebody was desperately trying to... Yes. It looks like somebody was desperately trying to make a platforming program on an operating system designed to run on teletypes, which is exactly what happened. It does actually kind of work. So there are a few bugs that need fixing. One thing I didn't demonstrate is that Turbo Pascal doesn't scroll the screen properly. That's a terminal bug. I need to figure out what's going on with that. But other than that, it basically works. This is a really nice machine for running CPM on. This is currently running in text mode with inverse, bold. There may be a TALIC if so, I haven't figured out how it works yet. Yeah, it's a really nice system. So anyway, I am going to finish the video here. All the software I've written is uploaded to the CPM-ish repository on GitHub. So if you have a SuperPound out, please give this a try. This is a standard PC format disk. You build the thing and then you DD or raw write the image onto the disk, and then it just works. This would be an excellent system for doing things like playing the Infocom games on if you like the noise of the disk access in between moves. So thank you again to the viewer who donated this to me. I really appreciate it. And if they or anyone else has enjoyed this video, please let me know what you think in the comments.