 So, in a previous video I showed off my nice new brother WP1 word processor. Let's do some more work on it. So I have it spread out on my desk here and dismantled. This time we do actually have a working machine and working video which you should be able to see here. Now you notice that the video quality is kind of terrible. I was hoping to get an actual video capture using my nice new OSSC. Unfortunately this thing won't lock on to the video signal produced by the board. Don't know why I'm still working on that. So what I've done instead is to mount the monitor part of the case over here and have a phone pointing at it and then use lots of video processing to try and make it readable. It's more or less working, more or less anyway. I'm not actually going to talk about the word processor half at all because I'm not really interested in that. What I am going to show off is this. I have a port of CPM to this machine. So what we do is we insert it in the drive like so, power off, hold down code and cue, power on and it boots. This is running as a program under the brother OS. That way I get access to the ROM routines for working the floppy disk drive which is otherwise a pig to drive yourself because there is no floppy drive controller on this. The floppy drive is hooked up to a simple gate array, this Moiro chip here. So in order to step the motor, I have to work the phase lines for the stepper motor myself. I have to do all the bit decoding myself and so on. So it's much easier just to call the built-in ROM routines and they work fine. The only issue is that we don't get to use the whole 64K of RAM, these two chips here. So if I fire up BBC basic, you can see the head moving here. There we go. I can calculate the amount of available memory. Let's try that again properly. So as always when I'm working one of these things, I can't actually see the screen I'm typing on very well. But Hymem is the upper bound of BBC basics workspace. Top is the top of the program itself. So this will give us the amount of free space in kilobytes, which is about 15K. That's all right. It's not brilliant for a CPM machine, but it's about what you got in the original BBC microbe. This is RT Russell's excellent port of Acorn's BBC basic. So and yeah, I can do, you know, programming things and just using the traditional program. And of course, because this is BBC basic, we get structured programming so that we don't need to use a go to and it works. So you notice there's a lot of snow and also not a very good frame rate. The snow is because the video RAM chip, which is this one, isn't dual ported. When the video chip, which is this one, is reading from the video RAM in order to display something on the screen, then if we try to write the video RAM at the same time, then it disrupts the video chip and you get that snow that you can see. It's completely harmless. The original IBM CGA video card did this. There's an easy work around because the video chips got a bit in one of its status registers that we can test for to tell us whether the video memory is in use. So all you have to do is wait until that's not set and then do the right. But I couldn't be bothered. So I'm just going to live with snow for the time being. So yeah, that works fine. If you go back to CPM, here it is reloading CPM of disk. The rubber band that I'm using as a belt isn't really very good. And occasionally the drive motor will slip on the belt, which is a little disturbing, but seems to be harmless. So we have a few other programs, including camel 80, which is a fourth interpreter. This is a stack-based language. So if we do this, that will push one and two onto the stack, add them to produce three and then the dot will display the result. There you go. It's always nice to have that confirmed. We can define our own programs. And you notice there is the exclamation mark that you can't type using the word processor software. So I think that's right. That is not right. I keep getting the colon and semicolon the wrong way around. The keyboard map on this thing is a standard UK ISO layout, which does not match what's on the keycaps. And on top of that, I've just used BBC Basic, which means that my fingers try to use the old-fashioned BBC Micro keyboard layout. And I keep typing the wrong thing. Anyway, there we go. We have to find a word in the system, which we can run. Works fine. So let's go back to CPM. And there's a bug which I need to fix. You've got to type that in lowercase. Here it is reloading CPM. There you go. Now, unfortunately, this port isn't really useful for anything. I would demonstrate like assembling a program. Unfortunately, the system call that I found to write to the floppy disk doesn't seem to work the way I expect it to. I mean, it works, but it tends to corrupt the disk. And I don't know why. I've reverse engineered the ROM to find these. And I have actually found the piece of code that formats disks and writes the file system to it. So I can see it using this system call to write the directory table in the FAT. And as far as I can tell, I'm doing it all right, but it just doesn't work. It's also incredibly slow and very clunky. And I think that without more information, it's just not really very helpful. So I'm going to stick with this as a read-only device for now. This should be fine given what I actually want to use this machine for, which I will get onto. My original plan for this thing was to use it as a terminal for a Raspberry Pi. I have a few spare. There's plenty of space inside the case. I could connect the Raspberry Pi up to the UART, belonging to the processor here, and use it as a terminal, giving me access to a much better grade of machine, but still using the excellent keyboard and the quirky little monitor. I originally thought this because I'd spotted that the UART, which is these pins here on the ECPU, was wired directly up to this port here. And I soldered some pins on, which you can see there, and did some experimentation. Sadly, this turns out not to be viable. The problem is that the keyboard, which is connected here, while it is connected up to a different peripheral on the CPU, one of the keyboard lines is connected to the UART's RX port. I can send bytes from the CPU to the outside world via the UART, but I can't receive them because the keyboard has got the line kept high, which is really annoying. I don't know what the keyboard is using that line for. There's no reason for it. I mean, if it was wired up to the TX line, then I would expect that it was a way for the computer to signal the keyboard to turn an LED on and off or something like that. But it's not. It's the RX line. Why is the keyboard trying to send serial bytes to the CPU when it's connected up to the synchronous serial interface, which works much better? I don't know. So that's out. So I'm going to have to go with something rather more hardcore, which is more fun anyway. And that brings me to this port. This is an expansion port. When I got the thing, it was unpopulated. You can see the footprint here for a connector. This lines up with a slot in the outer case. My belief is that Brother was intending to sell add-on hardware that would just plug in the side of the case and provide access to probably other kinds of printers, that sort of thing, maybe a modem. Unfortunately, I don't think they ever finished it. I say this because while this is wired up directly to the CPU's address and data lines, it is not wired up to the CPU's control lines for the bus. These are used by the CPU to tell the rest of the computer that it's doing a read and write from either memory, these two chips, or one of the IO devices, which is this chip or this chip or this chip or probably one of these or this chip. Now, there are control lines on the connector. They are wired up to these two chips here. These are gate arrays. They contain arbitrary logic that gets programmed into them before the chip gets soldered onto the board. I have no idea what that logic is. The only thing I can see is the program in the ROM. And of course, the ROMs are not talking to the expansion port. So one of two things could have happened. Option A is that the gate arrays are intended to contain logic to do stuff like address decoding, and then they control the control lines on the expansion port to let the control hardware know that the CPU is trying to access the expansion hardware. Option B is that the expansion hardware is supposed to tell the PALs that it's present, and the PALs then enable various bits of logic, such as routing the IO lines to the expansion connector. I feel that whatever it is, I can't figure out how it works because I don't know what the logic is in the PALs that make this happen. And it's possible that the PALs were never actually programmed with this in the first place. The fact that this port is unpopulated makes me think that they just gave up on this feature. None of the other Broads of the Word processors have this, as far as I know. So if they didn't program this into the PALs, I'm out of luck. So instead, I'm going to do something else. You notice that I have soldered some pins on here. These two are just power, plus and minus. These three are the three control lines. They are connected up to the CPU control lines here. I traced the signals. So using these three and this expansion connector, I should, I hope, have access to the entire CPU bus, or at least the bit I'm interested in, which is the IO side. This processor has got two buses, one for memory and one for IO devices. There are two lines, which is IO-enabled and memory-enabled, for distinguishing accesses between them. So I think I should have access to all the appropriate hardware. So I just need something to plug into it. And that brings me to this. Focus, focus. Yeah, focus, good. This is a very cheap PSock 5 development board. I think it costs me the equivalent of $5. I'm talking about this half. I'll get on to this bit later. The PSock 5 is a embedded ARM processor with a small FPGA glued on the side. It's the same chip that I use for my flux engine floppy disk interface project. This is actually a slightly more primitive and cheaper version of the one for the flux engine. It's got loads of IO ports. That's all of these. It's got a mini FPGA allowing you to wire up arbitrary logic to any of the IO ports. It's got a bunch of onboard peripherals, such as serial hardware, which I'm going to use. And the processor itself is a 80 megahertz ARM with, I think this has 32K of memory. This one is connected via this break-off piece here to a simple USB serial bridge. The idea is that you plug this bit into a computer. This then shows up as a COM port. And it allows you to program and or communicate with this via this thing's UART, which, let me get that the right way up, are these four lines here. So you've got TX, RX, ground, and VDD. In fact, I am not going to program this thing with this because this is not a true JTAG programmer. It's just a USB UART interface. And so in order to program this with this, you need to install a bootloader onto this that programs itself, which is really annoying. Some facts I'm using this, which is another PSock chip. But this one is programmed as a JTAG programmer. So I plug this into the computer I used to program it. And then I can update the logic on this basically on the fly. And the garnish on this thing and the reason why I'm using this is because this whole thing runs at 5 volts, which is pretty rare today when the world has moved to 3.3 volts and is compatible with the computer. So I should just be able to plug this directly into the various connectors on the brother word processor. And I can program in my UART logic into the FPGA, although I'm actually going to use the built-in UART for that because it works kind of better. And it's not a very big FPGA. And not need any more hardware. And if you have watched any of my videos before, you will know that I'm not really a hardware person. I'm much more comfortable with software. But first, we need to plug this into this. And that is where this wonderful cable comes in. This is a thing I made up. It plugs onto the expansion connector here. And it breaks out various useful things we have around. This is the 8-bit data bus. This is the bottom 8 bits of the address bus, which is the only bit I'm interested in. And this provides power and also three fly leads that are going to plug into the control lines. It also provides this thing, which is wired up to the reset switch, which is going to be really handy because I expect to be crashing the computer a great deal. So this plugs in here. Let me try and plug that in the right place. There you go. Plugs on like that. These three wires plug on to these three pins here. These are at an angle because, eventually, I wish to put this thing back into its case. And there's not a lot of headroom here, like so. Then this thing is awful. We plug these three connectors into the PSOC board. The power one goes here. We're going to power the PSOC board from the brother, like so. We then, this one is data. And we look for the little arrow that tells me which end is 0. We're going to plug this into here. This is, well, all the pins on the PSOC board are arbitrarily remappable. But just to keep myself sane, I'm using port 2 for this. This is the address lines. This is going to be on port 0. Where is that arrow? There it is, which is here. And this, the programmer, plugs into a USB cable coming from my desktop PC, which, as you can see, is powered. And that should, hopefully, be all the hardware modifications I need. You can see the lights have lit up on the board. Apart from, of course, plugging this into the computer I want this thing to talk to eventually. And hopefully, that's it. Everything else is a software issue. So let me just power the brother back on. And hopefully, it'll work. It's not working. Right. I bet I know why it's not working, which is these control lines are probably interfering with the computer's ability to actually run. I will need to try and let the, this thing is probably driving these. So let me try this now. There we go. And it now boots up CPM perfectly all right. OK, so I won't be able to wire these up until I've done some work on this if I want the computer to run. However, the first chunk of work, just turn that off again. I don't actually need this. So I might as well put these back on again. And I do need to try and remember which pins they go on to. So this is the first, second, and third. And let me just grab the meter. Let's do some continuity testing. OK, so gray and blue are the read and write lines. And red in the middle, well, purple, is the IO enable line. So I just need to try and remember that because the next chunk of work isn't going to be happening on the workbench because I need to go and pull up the Cyprus development kit, which runs under Windows. That is the big downside of these things. So see you on the desktop.