We're about to start. Please be quiet. We can start with John by Julioff about a journey
documenting the Sanko 8023 computer. Hi. Welcome everybody. My name is Giovanni Battista,
but everybody calls me Giomba. I got my master degree in computer engineering in the University of
Pisa, which is in this nice place. I'm working as an embedded software developer, so I do low-level
stuff, microcontrollers and some Linux drivers. And as you may imagine, I'm a retrocomputer
enthusiast. I wrote some games for consoles and retrocomputers, and you can find me on that
place there. And here with me, there is Julioff. Hello everybody. Can you hear me? Yeah. My name
is Julioff. I studied in Pisa too as an electronic engineer, and I like so much Pisa that I stay
there working because I work in Pisa as a firmware engineer in a company that produces cameras.
And today, I'm here to talk with Giomba about one of my hobbies, which is retrocomputing and how we
investigated about an old vintage computer, which is this. The story is funny because one morning I was
going to work by bicycle. That's not me. I was going to work by bicycle. When I saw on the
sidewalk this computer, this old computer, which was an old one computer with CRT monitor, floppy
disks and so on, and it was abandoned there. So I looked it. There was a cheddar label on it. It
said nothing. I searched on the Internet what it could define nothing, and I decided to take it, save it from
a dump. Another computer in the house. I started searching about it, and with the help of some
friends, I found out that it was a clone. A clone of a computer produced by Senio and Koflec, which
are French, Japan companies. And it's a true company. A company producer. The true producer was
Sanko. So our cheddar computer was instead a Sanko. This further information gave us nothing
more because on the Internet, we couldn't find anything except some photos on Wikipedia and some
advertisements. No technical information, unfortunately. And so we decided to do reverse
engineering on the whole computer. If you try to open a Sanko, you would find a single big mother
board with Z880 CPU. Some peripheral chips, common chips for the 80s, like the one to
interface with the monitor, the one to interface with the floppy disk, and so on. Some memories,
RAM memory, RAM memory for the program, for the BIOS. And around them, a ton of 74 LS gates. So this
motherboard is quite self-documented because it has no custom chip. All full common logic and pretty
common integrated circuits from the Z80 series and Z80 peripherals. And so you can continue.
And so we had never done this before. So the first thing that we thought that was sensible to do was
just to start and dump all the ROMs that were on the motherboard. So there was this first one that was
a common standard 2732 ROM. We dumped it and we thought, well, let's run a disassembler on it for the Z80.
And it contains a lot of things that made sense as a Z80 code, as you can see. Of course, it was not all
easy because this is just a huge binary blob. There is no differentiation, of course, between text and data
sections. So you just have to be creative with understanding what this code does. And we found out that a lot of
code made sense if it was placed at this address here, C000. But as you may know, the Z80 starts from, boots from
address zero. So this was something odd that everything was starting from C000. And in order to confirm this, we used
some logic analyzers just to confirm that it was actually a Z80, not some custom Z80 variant that started from
another address. So we found out that it actually booted from zero and then started to C000. It was a bit odd, but in the end
we found out why. And this contained the BIOS. Let's say that we have disassembled it. You can find it here. It's not
complete, but it's enough for what we are interested in too. And then there was this other ROM here that, well, as the name
suggests, it is a character generation ROM. Again, it was pretty easy to understand what it did, because we just run the
dump into a matrix. We started putting different configurations for rows and columns. And we found out the characters that were
inside the computer. And then this was this one here. It is an old 28-22 ROM. It is a narrow plastic
line package. It is a bit odd. We didn't have any programmer to dump it. So we built some wires. We had an Arduino. And there were
a lot of patterns, repetitive patterns there. We thought that it was something related to some glue logic for the computer, but at
the point we didn't know anything about this. So our first hacking attempt. As you can see here, on the system ROM, it is this
label that says V1.01. And if you turn on the computer, it says V1.01 on the monitor. So maybe there is some correlation. And yes, in the
dump we have a correlation, because we found it here. So let's find in the ROM where it is that it uses this string here. And we
found it. And we modified the ROM in order to make it display something. We discovered that this was just some memory-mapped
area for the video display. And in order to, at this point, we had to understand what the various peripheral did of this computer. So we
started patching the ROM with our own code. So we installed the Azure Insertion Force socket on the motherboard without damaging it, of course.
But at a certain point we realized, well, why are we switching the ROM continuously? We can just write our own bootloader with lots of things from the
serial in order to make our experiments. And our experiments were targeted at finding out how things worked in the Azure computer and to confirm or deny
our assumptions about the schematics. And speaking of the schematics.
Yes, speaking of the schematic, to better understand the software we had to better inspect the hardware. So what we did? We first
started reading the manuals of the integrated circuits, the standard integrated circuits in there. And we tried to find the connection between them,
because these data sheets were quite well documented. So we found out and we verified using a multimeter some of the basic connections. And we
drove them on a piece of paper. But that was not enough, because we had to better inspect the motherboard. Not all connections were written on the manuals.
So we had to have a better view of the motherboard. We were initially scared by the motherboard, because we suspected that it was multi-layered.
And it is. It's a four-layer board. But fortunately, it follows a very common standard where power rails are buried in the inside
ladder, in the inner layers. And signal traces are in the top and bottom and top layers. So it's quite simple. You had only to follow tracks under
chips and something like this. We took a photo of the motherboard and we started drawing the traces on it to keep in memory, to keep in mind where the traces were going.
And that's how we reverse engineered the board the simplest way, I think, you know. We used GIMP, free software. And then we moved on
to the key card. So after the discovery of all the traces, we put them on a true schematic. This is not a true schematic. This is a true schematic.
And quite 90% of the schematic is understood for us. The other 10%, which is mostly the floppy disk interface, is quite messy, but is copied on the key card.
The whole board is on key card, but we understand quite the 90% of it. And let's talk about some of the pieces of the schematic.
First of all, the memory map, the memory management. So John Bassett before, no, later. So the Z80 has 64K of addressing space and is quite all-mapped dynamic RAM main memory,
except for some holes for the video memory, main ROM, et cetera. And the addressing of these holes is done by the coder chip that matches the first digit of the
XADESHIMAL address. And it enables the correct peripheral. When none of the holes is addressed, none of these, the dynamic RAM is enabled in place.
But there is more, because if you want to address the whole dynamic RAM, you can turn off this decoder through a switch signal and address always the dynamic RAM.
This mechanism is known as bank switching. But John Bassett before, the Z80 starts booting from address zero, but the ROM is at address C, C000.
How is this even possible? Because you would read garbage from RAM at boot. It's simple. There is a latch circuit that at reset or boot, it forces the ROM enable until a particular instruction from the Z80 is executed and it disables the latch.
In this way, you would have this memory map with ROM all over the addressing space until the particular instruction is executed that restores the correct addressing space. So the code had to jump in the correct area and to execute this instruction.
And this way is booted and with the correct addressing space. This latch is never used until the next reset.
So one interesting part that we tried to understand at first was the video generation and all the video generation is done by this CRT controller that knows everything about the timings of the system for video generation.
This is a very interesting information. It produces the synchronization pulses for vertical and horizontal and it always knows what it is displaying at that moment. So it can generate memory address to retrieve the character that is being displayed in that moment.
Let's assume that this is what it is on the display. So it generates an address, for example, for the first character top left. This takes out the index of that character, which is fed into the character ROM. So this is the character with that we want to generate it to display.
But it also knows which of these lines are being displayed at the moment through this path here, as you can see. So this selects one single line, which is then fed to this shift register, which is clocked at this speed here.
And it produces a pattern of dots that if you are familiar with video signals, that's what it looks like, like the synchronization pulses and the data. But all of these also has some other interesting things peculiar to this computer.
We have the video ROM, but we also have another memory, which is the attribute video memory that produces some bits that are fed into these combinatorial networks that we had to understand what they did.
And speaking of combinatorial networks, well, you know, you can describe them using a truth table, but you may wonder now why didn't I put here input and outputs, but I put here address and data, because you know the answer.
Well, combinatorial networks are just read only memories, so it can be implemented by these mysterious ROM here. So that's what it actually does.
So we could generate all these effects by simple networks like this one, like two exclusive or gates that are triggered and can produce an inverted signal like this, or some other effects can be generated by shifting gear, as I say, that just clock the output shift registers at half the pixel clock,
and this generates wider pulses for the data so that you can produce wider characters. And then the other network that we have is the vertical stretch one that simply replaces all the accesses to the character generation in order to address the lines twice.
So instead of zero, one, two, three, you have zero, zero, one, one, two, two, and so on, and you have characters that have double in height.
Since they say that the Sanko is desktop computer in the actual meaning of the word that it takes a whole desk, in order to work with this, we built our own adapter for the video signals that is based on an RP2040, as you can find it here.
And so in order to make us able to connect to a small VGA monitor so that we could use on a desktop in a more compact way.
Okay, and you should know what is this, I think. We have no software for this computer, so this is not a Sanko floppy.
So when a friend of us published on the internet the CPM operating system for Sanko computer, we had to create our CPM disk for the Sanko computer.
So we started studying how to manage floppy disks with the Sanko. We studied the BIOS routines. We learned how to write format read floppies.
And we studied the floppy image of the CPM. In this way we were able to write a custom Z80 code able to transfer information from Sarah Port through to the floppy disk.
And together with this custom Z80 code, a Python script on the PC side able to transfer the whole disk image to the computer through serial.
This process, this whole process took about 20 minutes. I did it at midnight, the day after I had to go to work.
I left it to writing and the next day we had the CPM operating system booting on the computer. In a single shot we were very happy to be able to do this with a single try.
But we still had a huge problem. We didn't have the keyboard. How could we use this computer?
A friend of us had this one in a working condition. He provided us with this truck that was transmitted on the wire of the keyboard.
It was simply a serial. We built an adapter so we could connect a common modern PS2 keyboard to this computer and use it as a real computer.
We also thought that all this knowledge was not enough to put in some repositories with some documentation with images and schematics and so on.
So we started writing our own emulator that at this moment has a working Z80. That's easy because we use a third party library of course.
We have interrupts that work in mode 2. We have the correct emulation of the CRT controller with all the effects that I described before.
We have some serial peripherals. Among them there is the keyboard.
This emulator allows you to debug your programs for the computer because it has an integrated monitor. You can set breakpoints, inspect memory and so on.
Now there is currently a working progress for emulating some peripheral I.O. with GPIO.
The floppy disk which is in a half working state at the moment. Since the project is starting to grow and grow, we need to add some tests.
But I need to show you the killer feature of this emulator which is this one here.
Oh, it makes a beep.
So we need help with documentation, software and people who want to help us discover more about this computer because it is quite mysterious.
So if you want you can join us. You can find everything on GitHub and help us.
And now there is some time for the questions I hope. Thank you.
Maybe we can take one or two very quick questions.
Hi guys. Very nice work. Thank you.
I was wondering if you compare this to a Sinclair Spectrum architecture because it looks really, really similar except maybe for the character generation.
All the addresses there. Have you done a side-by-side comparison of some kind of thought about emulating a Spectrum 48K?
Don't. I downloaded a lot of similar computers. I don't remember at the moment. A lot of computers that use the Z80 as its core.
The Osmo uses the Z80 as its core.
So I tried to compare them but they are all similar but not the same.
There is everything that is different. Every time something is different.
The strange thing about the boot ROM is documented online on a website that talks about the dynamic RAM refresh.
But I have never seen it in other computers. So if someone knows this strange mechanism, feel free to.
The site was about the dynamic memory refresh and it talks about the strange ROM substitution too.
So the mechanism that allows the computer to boot even if not in C000.
Okay offline.
Yeah, I'm afraid we have reached the time. Many, many thanks.
You're welcome. Thank you. Thank you.