 My nice new brother WP1 word processor. I could connect the Raspberry Pi up to the UART. Sadly this turns out not to be viable. This is a very cheap PSock 5 development board, and wire that up. And nothing has happened. Next time we'll come back with some Z80 machine code. It is a whole 65 bytes. Okay, that's interesting. The ACK bit has been lost. So I actually think I have a solution, although I'm not quite sure why this works. But this is now mostly working. I think I have made this work, although I'm not sure why it works. After remembering that we were dropping bits to the status register when the edge detector was here, I tried removing the edge detector from the output of the bus interface to the flip-flop that is storing the result. And now everything seems to be fine. But I don't know why that should make a difference. I know that the CPU clock in the brother machine is running at about 6.25 MHz. And the clock in the interface is running at 17. So they are going to be drifting in and out of phase with each other. And I reckon this is probably something to do with it. But this is why I was trying so hard to make sure that the output was being sampled correctly at the beginning of the bus transaction. So I would have thought that simply wiring the output enable line directly up to the flip-flop should actually make things worse. But it doesn't. It makes things better. So I'm not really sure what's going on there. Clearly the obvious thing to do is to simply run the interface of the same clock as the brother. And in fact we can do that. There is a clock output line on the brother that we can tap into. And we can then configure it to use an external clock. However you can't select pin. And I'm using port zero for one of the bus inputs. So I would need to do some rewiring. So I'm not going to bother since it does actually seem to be working. At least I hope it's working. I spent some time fiddling with this and nothing bad happened. But yeah I will actually remove this debug stuff. Should do it. And I will build and flash it. And then oh yeah we do need to provide a value for that. I don't want to actually remove the LED pin because I'm sure it's going to come in useful later. So we start up pterm. And it loads. And now we can type and it should come out on serial terminal. So not one bad character. It does appear to be working. And I can type on the serial terminal. Again I need to put it in the mouse pointer in the right window. And you can see the text coming out on the brother. So I think that is done. Which brings me to the next part of the problem. Where I have to, if I can try and get this on camera. Whoops that ain't going to work well. I have to hook this thing up to a Raspberry Pi. Now I could just plug this in to the Raspberry Pi via the USB connection. But I would rather wire this up to the Raspberry Pi's native UART. Which are these, so I have to connect to these four pins there. So let me just turn off the various bits of hardware. Okay we've got the lights out. So what I need to do is to remove this bit. And then hook up a level converter to this bit. So I need to snap this off. Come on, don't break, perfect. So now I've got this separate from this. I can reuse this as a TTL to serial converter. And also you can program this chip to do things to the input-output ports. This is still quite useful. And this, I can solder some pins in to get access to the UART terminals. So I will go away and do that. I have soldered on the pins. These four here give you respectively TX, RX, GND and VDD. VDD being the 5V supply from the brother. And over here I have the very elderly Raspberry Pi model B, I believe. I can't remember. It does say 2011 on it, so it's about 10 years old. I'm using this because it's so old that it doesn't really matter too much if I explode it. Although I'd rather not. Now, all I really need to do is to connect up this custom connector made out of hope and hot glue. And that gives me power and RX and TX. Unfortunately, the Raspberry Pi is a 3.3V device, and this is a 5V device. 5V is great for talking to the brother, but not too good for the Raspberry Pi. If I were to connect them together directly, I would probably fry the Raspberry Pi. And that's where this thing comes in. This is a level converter. It converts between 5V and 3.3V. And luckily the pinout is convenient, so I can just plug this on in the right place. See, there we go. So that we've got two data channels on the high voltage side, ground and the high voltage. And correspondingly over here, we have the same for the low voltage side. So what I need to do is to hook up ground to there. This is the 3.3V line from the Raspberry Pi, so that goes onto the low voltage. And then let me see. Orange is TX from the Raspberry Pi, so this needs to be connected to RX on the interface. Happy this one. And this is RX on the Raspberry Pi connected to TX on the interface. Like so. And that should be all we need. So I will plug everything back in in hopefully the right place. And it seems to have lost a cable. Oh right, I didn't unplug that from the board unless disassembling it. And we'll see if it all works, I suppose. Okay, moment of truth time. Peter is running. I have the Raspberry Pi set up and ready to go. All I need to do is plug in the power. So let us do so and see what happens. I'm going to guess nothing. That does seem to be nothing so far. Well, I have news. As you can see it is sort of working. I had to do a bunch of really stupid fixes ranging from the control lines not being plugged into the right pins here. The control lines being plugged in backwards which made some really strange things happening. A frayed wire causing D0 to float high. A bad crimp which turned out that one of the address lines was not in fact connected. But now that it's all done, it sort of works. I mean sort of. You can see that I am successfully interacting with the Raspberry Pi. Sort of. Now I had to bump the board rate of this thing up to 115.2 because that was what the Raspberry Pi was set to. And I don't think this as a whole is capable of dealing with that. And as a result I believe it is dropping characters. You've noticed that characters I type seem to be fine. That's because I'm typing quite slowly. But when lots of... That's me trying to press the delete key by the way and it's not working. Control. Go to you. Yep. But when the Raspberry Pi is talking back to the brother it's of course sending big chunks of data all in one gigantic go. And it ain't working. So in order to deal with that let me try and get the keyboard on camera so you can at least watch me typing. At least to a certain extent. So I think what I would need to do is to modify the init tab which doesn't actually appear to exist. Interesting. What I would have to do on an ordinary Unix system that used init is to modify the init tab to change the board rate of the serial console. This of course won't do anything for the boot time serial output which is irritating. I'm not quite sure what I could do about that. The trouble is that there is no handshaking between the interface and the Raspberry Pi. I mean I could use CTS RTS handshaking but there just isn't any for the UART on this thing. Although now I say that I think it does support it. It's just not exposed usefully in the serial port. I have another couple of channels spare and the level shifter. I wonder. I'm going to just lower the board rate for now so that the Raspberry Pi is going to talk at a speed that this thing can cope with. I think back down to 19.2 will do. To my complete surprise the built-in UART module on the interface does not support flow control at all. I can build my own UART out of FPGA logic. There's a component I can use to do that which is very easy except there isn't anything like enough room with my own custom logic. So I'm just going to go with no flow control. So I have changed the board rate on both the interface and the Raspberry Pi. We seem to have a lot of garbage on the screen that appeared when the Raspberry Pi turned off. So let me reboot it and see what comes out. Okay, red light. That looks plausible. Lots of snow of course. I need to fix that bug. But that looks more or less right. The annoying thing is a protocol I came up with where the brother talks to the interface does actually do flow control in both directions. I probably didn't need to do that actually. I just needed to make sure everything was timed correctly. Anyway, might as well do it properly I suppose. So I'm just waiting for boot up. Here we go. I'm not sure why it says Raspberry spelt incorrectly. Here we go Raspberry Pi login. And that mostly seems to work. Okay, let's set the terminal to BT52. My BT52 emulator on the brother is kind of buggy. No, no, sorry, it's not BT52. It's worse than that. It's ADM5A. Yes, that's much better. I wonder, will VI work? They did not actually seem to set the right terminal. It's possible that the ADM5A, which is a really simple terminal, the original ADM5A terminal emulator was built entirely out of TTR logic and had no microprocessor at all. Oh really, that's been modernized. I am actually seeing the occasional dropped character. See it says, etcterinforeadme. Yeah, look at that. You see where object is. Yes, that's not quite right. I'm trying to find the name of the ADM5. It's mostly functional AD. What do we have? Oh, it's just ADM5. Export term equals ADM5. How's that looking? VI. Well, the I's in the background are, I think, a bug in my terminal emulator when it clears the screen. So I think that's my fault. But the text does appear to be in the right place. We can cursor around. Wow, you know, I think this is actually working. That's amazing. Okay, let's quit out of this. It doesn't know the screen is only 15 columns high. So let's try rows equals 15. Let's try that again. No, I don't think that's... Or is it lines? No, that's not working. Resize will tell me... No, it won't. Apparently I don't have that. Yeah, this is working. There's a bunch of loose ends that need fixing. But I can get stuff done. Now, I just need to try and find... This Raspberry Pi does not have Wi-Fi. So let me just hook up an Ethernet cable. Like so. Okay, it's not brilliant, as I said. But it is working. That's great. Well, I did a whole ton of bug fixing in my CPM terminal emulator. And I seem to have mostly made it work. There are some problems. Now, the first thing you'll see from the spam scrolling up the screen is there's still tons of snow. I did find out how to check to see whether it was safe to write the video memory. Unfortunately, the bit that tells you when the video memory is in use doesn't seem to work on the brother system. So instead I have to use the vertical refresh. That means I can only redraw once every frame. Which isn't so great. So I haven't turned that on because it ends up slowing down the text output to like 62.5 characters per second. The second thing you'll see is that the board rate is kind of slow. And it is in fact a bit too slow to be useful. Let's try that again with the right command. So it takes time to do everything. I mean, it works. Like VI is perfectly usable, provided you want to use the letter keys rather than the cursor keys. But if I, for example, try to look at a man page, then things like scrolling up and down are just too sluggish and a bit too weird to be particularly pleasant. Looking at the man page also shows up another issue. So let's go back to the top and see it's taking too long. A lot of the lines of text have an M at the end of them. Now this is because Linux is really keen on sending anti-escape sequences even if the terminal you're using doesn't support them. And I haven't figured out if there's a way to turn these off. Of course the ADN3 doesn't understand anti-escape sequences. And I don't really want to put in support in CPM for dealing with them. Like, I just need to ignore them. I don't need to do anything with them. They can be parsed correctly or you get spam. And there's a bunch of other things that show up as well. Periodically you'll see a 2004 appearing and the prompt. And this is the escape sequence that's used to deal with bracketing pastes, which is the facilities that allows you to paste text into a terminal and not how it run lots of random commands you don't have a chance to check. That's not so hot either. So I think that even though this is all technically working, I mean there's still a few features I want to support like reverse text. I am actually going to take the time to write a whole new terminal emulator that supports probably VT100, maybe ANSI. I'll need to check to see what the actual difference is because it's a bit subtle. And hopefully I will also be able to make it run fast enough to run reliably at 19.2 kiloboard. Because that might be fast enough to be usable. In fact, I know it'll be fast enough to be usable. 9600 board, which is what this is, is only just a little bit too slow. Also the main thing I actually want to use is my word grinder program. Which writes out a lot of UTF-8 control characters, which of course the terminal emulator in CPM doesn't understand because CPM supports 7-bit ASCII only. So having something that can at least parse them if not actually print them will be nice. And given that this thing has got quite a good character set, then actually supporting UTF-8 would be nice. So I am going to cut this video short here because the next one is going to be long and is going to be me writing Z80 code on my desktop. Also I discovered that when I did a ton of video editing the gain on my desktop microphone is all wrong. So all my desktop audio has been sounding weird and crackly because I've had to bump the gain in post to make me audible. So that's nice. I'll try and get that fixed for next time. Anyway, until next time.