Project Logs

Collapse

• Sokath, his eyes uncovered!

  Marcellus Pereira • an hour ago • 0 comments

  Last time, the walls came down. This time, we understood why. All five walls of them.

  Yes. Five. But let’s not get ahead of ourselves.

  With the CPLD test program running smoothly, I was feeling pretty confident. The slot selector worked, the sub-slots worked, the memory mapper worked. Almost too good to be true. <<Insert a happy smile here>>
  
  Instead of using an MSX2+ ROM, which would be very difficult to modify, I chose to use C-BIOS, a community project for a basic BIOS for MSX computers that avoids proprietary solutions and was designed for use in emulators. It’s not exactly what we need, but the available source code is a huge help.

  After a quick modification, it was being compiled by ZDS—Zilog Developer Studio—for the Z380. I didn’t make any major changes, just the initialization of the internal registers.

  I burned the BIOS and the sub-ROM to Flash memory and… garbage.

  And not even the kind of garbage that’s one person’s treasure. Random garbage, different with every boot.

  Wall Number One: The Ghost Slots

  C-BIOS searches for RAM by writing a byte and reading it back. Makes sense, right? Except that, on this board, an *empty* slot responded to the command. The data bus, apparently due to parasitic capacitance, retains the last value written to it—so the C-BIOS wrote a byte into the void, the void politely echoed it back, and the C-BIOS happily selected a slot with no memory chip. My machine believed in ghosts.

  The fix was made in the CPLD: any read of a slot that doesn’t have an actual device behind it now returns $FF. No more séances on my data bus. It’s not the definitive solution, but it’s what we have for now.

  Wall Number Two: The Lying Registers

  It was possible to write to the slot registers, but when I read them, they returned a strange value. The CPLD was recording the read data at the bus clock—one cycle late, every time. A flip-flop was downgraded to a transparent latch, and the registers stopped lying.

  Wall Number Three: The Two Worlds

  This was the big challenge—the one that had been haunting this project for *months*.

  The code copied into RAM refused to run. It wasn’t a “spectacular failure”—it was worse. It would run, return, and politely spit out garbage. Always the *same* garbage.

  I had to connect almost all the cables on my data analyzer. It looked great on the board; I had to solder a few terminals on the underside… but the data analyzer finally revealed what was going on. The Z380 writes individual bytes using address parity: even bytes here, odd bytes there. But when it *fetches words*—and fetching instructions from RAM is always done in words—it uses aligned addresses. My SRAM had its A0 pin connected directly to the CPU’s A0 pin, so that bytes written one way couldn’t be found the other way. Two parallel worlds—the world of bytes and the world of words—sharing a single chip and never agreeing on where things were. And here I was, thinking I’d eliminated all the bugs from the schematic.

  Every byte the program wrote to an odd-numbered address simply *didn’t exist* for the instruction fetcher. The C-BIOS copies its slot-switching routine to RAM and jumps to it. You can imagine how that turned out.

  The solution? A wire. I lifted pin A0 on the SRAM (remember: 0.50mm pitch, no microscope), soldered it to ground, and let the byte enable signals do their job. In Brazil, we call this a *gambiarra*, and I’m not ashamed of it. Well, maybe a little, but it’s a temporary fix.

  Wall number four: the impatient CPU

  With the RAM finally coherent, the C-BIOS booted up… and generated garbage again. But now it was *stable* garbage. *Good* garbage. Not a treasure, but good garbage.

  Progress!

  The V9958’s datasheet is quite clear: a minimum interval of 8 µs between VRAM accesses. The Z380, with its pipeline and four-IOCLK I/O transactions, hammers the poor VDP every 2.2 µs (if the clock is 3.58 MHz—imagine when I enable the 14 MHz!),...

  Read more »

• I love the smell of REBOOTS in the morning

  Marcellus Pereira • 06/21/2026 at 15:37 • 0 comments

  In the XRX, I use a voltage monitor chip from Texas Instruments, which also serves as the input for the reset button. It’s the TPS3828.

  If the supply voltage drops below 4.55V (typical), the chip generates a reset signal for the circuit. In addition, during power-up, it also ensures a 200ms reset pulse.

  The watchdog function, although present, is not being used in this project.

  Well, it turns out that the board would randomly reboot on its own. It didn’t happen all the time, but it did happen.

  There’s another reset trigger in the circuit, coming from the power supply. The “Power Good” signal is buffered and can also trigger a reset, but the oscilloscope showed everything was normal.

  The supply voltage also didn’t goes down 4.55V—it didn’t even come close to that. So, what could it be?

  Using the old “put your finger on it and see if it burns” technique, when I touched one of the pins on the reset switch connector, the board rebooted. A missing ground? It didn’t seem like it, but I resoldered the connector anyway.

  The problem persisted.

  I decided to replace the TPS3828, using the one from the old board. And… it worked.

  This is something to keep in mind when producing this board… but, for now, I can continue with my work.

• Shaka, when the walls fell

  Marcellus Pereira • 06/14/2026 at 16:13 • 0 comments

  I spent weeks—several weeks—trying to figure out what was going on.

  I wrote a very simple program that toggled a keyboard pin, and, of course, it wasn’t working. But it SHOULD have worked.

  Using a data analyzer, I monitored the address bus, the data bus, and some control pins on the Flash. And it was really impressive to see just how much more advanced the Z380 was compared to the Z80. Of course, you already know this from reading the manual, even though the manual is pretty superficial. But it’s one thing to read about it and another to *experience* it.

  Instructions executing in just a few clock cycles, the I/O bus completely separate from the memory bus, the internal (“phantom”) registers that simulate an instruction fetch cycle… it was an invigorating experience. So much so that I asked the chip’s architect for an autograph (more on that later).

  During that time, I discovered two things. The first is that I had completely messed up the pinout of the Flash memory socket.

  The second is that I had routed the SRAM data pins incorrectly.

  <<Insert happy face here>>

  This took me some time because the ROM is accessed in bytes; so to read a 16-bit value, the Z380 uses two fetch cycles. RAM, on the other hand, is accessed in 16-bit words, meaning that to read the same value, the Z380 uses only one fetch cycle.

  Since the ROM can be accessed in both slot 0 and slot 3, I spent my time looking for issues in the Verilog code for the slot selector, instead of focusing on the hardware.

  By the way, here is the slot map:

  ```
  +------------------+--------+----------+----------+--------+--------+--------+--------+
  |                  | Slot 0 |  Slot 1  |  Slot 2  |Slot 3-0|Slot 3-1|Slot 3-2|Slot 3-3|
  +------------------+--------+----------+----------+--------+--------+--------+--------+
  |  10000h~7FFFFFh  |        |          |          |  8MB   |        |        |        |
  +------------------+--------+----------+----------+--------+--------+--------+--------+
  | Page C000h~FFFFh |        |          |          |        |        |        |        |
  +------------------+        |          |          | 128kB  +--------+        |        |
  | Page 8000h~BFFFh |        |Cartridge |Cartridge | Memory |        |        |        |
  +------------------+--------|  Slot 1  |  Slot 2  | Mapper | Kanji  |        |        |
  | Page 4000h~7FFFh |        |          |          |        |        |        |        |
  +------------------+  Main  |          |          |        +--------+        |        |
  | Page 0000h~3FFFh |  ROM   |          |          |        |Sub-ROM |        |        |
  +------------------+--------+----------+----------+--------+--------+--------+--------+
  ```

  Since there was no use crying over spilled milk, I rolled up my sleeves and went back to the drawing board. I mean, to the CAD.

  I redesigned the board (still without the “X-Slot”), taking the opportunity to fix a few other minor slip-ups. One of them I later regretted: I had planned to include a UART, which would be implemented by the same microcontroller that would simulate the RTC. If I had kept that “feature,” my debugging sessions with the new board would have been much easier.

  Anyway, I also decided to have the board assembled by the supplier (I won’t mention the name here because they aren’t sponsoring me… but you know who I mean). For the first two versions, I soldered the components myself. But let’s face it, I’m past that age. I don’t have a microscope here, and soldering components with a 0.4mm pitch… so I took the easy way out.

  That saved me A LOT of time. Instead of spending days looking for a defect that wasn’t in the Verilog code or the assembly code, but rather a smudge of solder under a CPLD pin, I was now pretty sure the hardware was right. Or rather, I was sure that the board I had in my hands was exactly the one in my CAD.

  But I was now facing two problems. While the hardware was reliable, there were still the Verilog code and the assembly code to consider. Despite the verification and simulation, the CPLD was programmed to do what I *thought* it should do, with several “shortcuts” to save a few logic gates. And since the first attempt to...

  Read more »

• Music and their cool will at last interlace...

  Marcellus Pereira • 06/14/2026 at 13:02 • 0 comments

  I wanted the PCB to fit into a modern chassis, so it would have to be a standard size. ATX is too big, mini-ITX is too small. How about DTX? It’s not that common, but it would give me room to use other chips (V9990, I’m talking to you).

  But I’d have to make a choice: a VGA connector or a new slot with the Z380 signals? Both wouldn’t fit on a board that size.

  After much thought (well, not that much), I ended up deciding on the new slot (“X-Slot” is a completely innovative name, don’t you think?). A 1994 MSX *might* already have a VGA connector, but it would certainly be better to have a slot with the BUSRQ and BUSAK signals.

  So, all that was left was to choose the composite video generator chip. The Omega MSX uses the Sony CXA1645, but this component is no longer manufactured and, due to the project’s philosophy, couldn’t be used. I mean, I could have… after all, the PSG, the VDP, and the Z380 itself have already reached EOL. But in this case, there was an alternative still in production: the Analog Devices AD724 for a mere $15… :-/

  Well, that’s that. A quick look at the datasheet, everything seems fine. I can use the VDP’s CSYNC signal as a sync source… I can choose between NTSC and PAL... I can use the 3.58 MHz clock because the chip has an internal PLL… okay, everything checks out.

  “How hard can it be?”®

  It turns out there’s a small detail in the datasheet: the input signal needs to be *interlaced*. And even though the V9958 is capable of generating an interlaced video signal, I don’t believe MSX action games were designed with that in mind.

  In any case, it’s too late to change now.

  It took me a while to figure out why there was no image on the monitor, even though I was measuring a video signal with the oscilloscope. And when you’ve been poring over a problem for a long time, you end up seeing ghosts.

  After enabling interlacing generation in the VDP, things got a little better.

  But only a little.

• The other side

  Marcellus Pereira • 06/14/2026 at 12:09 • 0 comments

• The CPLD rabbit hole

  Marcellus Pereira • 06/14/2026 at 09:55 • 0 comments

  Well, the main idea was that this project wouldn’t use FPGAs. It’s not that I’m against hardware synthesis—I think it’s an incredible idea that makes many advanced projects technically and financially feasible. But I wanted to build this machine exactly as I envisioned it more than two decades ago.

  However... using dozens of logic chips these days doesn’t seem like a good idea to me either. So, I settled for a middle ground: I used a CPLD as “glue logic.” The question was: which one?

  I wanted to use a CPLD that:

  0. didn’t use a BGA package.
  1. had enough logic elements. How many? I don’t know.
  2. had 5V-tolerant pins.
  3. had free development tools (they didn’t even need to be open source).

  The biggest problem, in my naive optimism, was how to know if the number of logic elements would be sufficient. Knowing that the Z380 would access the VDP at four times the speed (considering only the clock, without taking the pipeline into account), I wanted to have a FIFO implemented between the VDP and the microprocessor. How many logic elements? I don’t know. Would it be possible to do this with a CPLD instead of an FPGA? I don’t know.

  So, the easiest (and by far the most expensive) way was to choose the largest CPLD that met the requirements.

  The choice was the Lattice LC4256V. Part of the ispMACH 4000 family, it has 256 macrocells (that number seems sufficient, doesn’t it?), is powered by 3.3V, but the pins are “5V-tolerant.” In fact, it has 128 I/O pins (that number seems sufficient, doesn’t it?). Lattice provides (provided) the development tool... so, everything seemed fine. Except it wasn’t.

  To cut a long, long story short: not only was it impossible to implement the FIFO the way I wanted (though the VDP data bus is still connected directly to the CPLD), but it was also impossible to implement a memory mapper that controls more than 128kB. I know, I know... maybe it’s my lack of skill with Verilog code. But that’s how it stands for now: 8MB that the program can access linearly, or 128kB accessed via the mapper. I’ll go into more detail about the memory later.

  Well then, CPLD chosen, development tool purchased... the chip in the development kit isn’t exactly the one I’m going to use, but it’s quite similar—what could go wrong? Well, the CPLD in the development kit doesn’t have “5V-tolerant” pins. 

  And to make matters worse, I couldn’t use the kit to program the CPLD on my board; I’d have to buy a tool from Lattice or try using an open-source project.

  The final decision was: to create the first version of the board using the CPLD itself (instead of pin bars I could connect to the external kit) and to make a small “hack” to the Lattice development kit so I could use it as a programmer. “How hard can it be?”®

  After all that, Lattice decided to stop providing free licenses to schools and hobbyists. The ispLever Classic tool now costs 600 euros... for one year! What to do?

  Well, it’s time to reconnect with old friends and catch up with your old college. Maybe they still have some old computers in the digital circuits lab with a valid Lattice license. BINGO! :-)

  Without getting into the legality of the solution, I could now program the CPLD on my prototype board. And considering the cost of the board *and* the components, it would be great if I hadn’t messed anything up the very first time. It doesn’t hurt to dream, does it?

• SRAM for the VDP

  Marcellus Pereira • 06/14/2026 at 06:45 • 0 comments

  If one of the goals of this project was to avoid using obsolete components, one of the biggest problems revolved around the VDP.

  The V9958 itself hasn’t been manufactured for decades, so I’d have to use whatever I could buy from more-or-less-honest brokers. But I didn’t want to do the same with the DRAM modules used with it.

  “How hard can it be?”®

  It’s not an original idea; this has been done before. 

  The first attempt had a small glitch, of course... but in the end I still managed to save one chip compared to Tom LeMense’s implementation.

• A bit of history...

  Marcellus Pereira • 06/13/2026 at 21:16 • 0 comments

  ### Zilog Z380

  The Z380 was introduced to the American market in 1994 by Zilog as an extension (and instruction set compatible) of the successful Z80. However, it had already been shipping to Japanese customers for a year before that but unfortunately none of them were willing to use it in an MSX-compatible machine. 

  Here is a small table comparing the different Zilog processors at the time:

  Zilog's original documents mention speeds of up to 40MHz, but I could only find the 18MHz version. We will not discuss the Z382 version, even more difficult to find these days.

View all 8 project logs