Overview of Zeal 8-bit computer and hardware update
ฝัง
- เผยแพร่เมื่อ 18 มิ.ย. 2024
- NEW: Zeal 8-bit Computer is now available on Tindie, check tindie.com/products/zeal8bit/...
Hello, world!
In this episode, I will give you an overview of the current prototype but also more details about the next hardware revision with its new features!
If you like this video and this project, please consider subscribing, this will help me and support me.
My previous video:
Build an 8-bit retro computer powered by a Z80 ! - • Build an 8-bit retro c...
A Discord is now available to talk about Zeal 8-bit project! Feel free to join: / discord
----
Keywords:
8-bit computer, 8 bit, retro computer, vintage computer, homebrew computer, home computer, computer DIY, CP/M, cpm, z80, zilog, PCB, FPGA, Altera, EP4CE10, amstrad, commodore - วิทยาศาสตร์และเทคโนโลยี
You are real engineer
Your fans from Indonesia
Thank you for your support!
Zilog does not only sell the old stuff but also new chips. I strongly suggest to have a look at the eZ80F92. This chip is still binary compatible to the original Z80 but much more capable and easier to work with. First it contains not only the CPU core but also two UARTs, SPI and I2C, parallel IO, an RTC, and 128k of Flash and 8k of internal SRAM. There are four programmable chip select lines for connecting external devices without addidional glue logic. The chip is 3.3V so you don't need any level shifters any more. And the best of all: The eZ80 core also has got 16MB of address space and 24 address lines. It has got internal banking logic and an linear 24 bit address mode where the registers BC, DE, HL IX, and IY as well as PC and SP are 24 bit wide. You can switch between 16 and 24 bit address mode. The eZ80F92 runs at 20MHz, which is similar to an original Z80 with 30 or 40 MHz since the instructions need fewer cycles. You also get an external debug interface from where you can peek into the registers and memory, execute commands, program the internal flash etc etc. Basically, your whole board would shrink to the eZ80F91, a 3.3V SRAM, 20Mhz crystal, 32khz crystal, voltage regulator and maybe two MAX3232 for the serial ports - plus the PS2 interface.
There is also an eZ80F91 which runs at 50 MHz and also contains a 10/100 Fast Ethernet interface. You will need an MII PHY for this (e.g. DP83848).
Thank you for your comment with all these information!
The fact is before starting the project, I had a look at the Z80, eZ80 and Z180. The Z80 and Z180 both have DIP package, which makes it very convenient to switch on a board, with sockets. I was really interested in the Z180 as it also embeds many peripherals, such as timers, UART, or an MMU. But it turned out that the Z180 is obsolete already.
The ez80 is awesome, it does have everything I need. After thinking about it for a while, I found that it wouldn't correspond to what I am looking for multiple reasons:
- It doesn't have a DIP package
- It runs faster, yes, but it also means the peripherals around it (more SRAM, Flash) would also need to be faster. The components provided with a DIP package may not all go as fast as 20MHz, which would be equivalent to 50ns signals (for example the DIP SRAM I use needs at least a 55ns write signal, but there is the logic also that takes around 30ns, so it total we need 85ns at least). Of course it would be possible to use the CPU's WAIT line to slow down the signal and give more time to external memory. But this would make the average frequency lower. With SMD components however, this won't be a problem because we can find faster SRAM.
- Using SMD components only for the main board would make the board much less user/beginner-friendly, which is what I would like to avoid. I want a simple board that anyone can repair/hack/understand.
- Using an MCU, in general, hides a lot of things for the users as some peripherals are internal to the chip so harder to debug its hardware signals
So, this is why I chose to use a Z80 for this project, BUT it doesn't mean I won't choose the ez80 for a future version 😁
I don't know, maybe a more powerful one ? A portable? Who knows 😄
@@Zeal8bit I see your points:
1. Supply of DIP packaged parts is fading because of worse electric properties (larger pin inductances and capacitance). However, SOIC chips are still quite easy to solder. And your FPGA board is completely SMD as well.
2. Sorry, this is not true. You stll can use slower peripherials. The internal CS logic can insert a programmable amount of wait states for each CS pin in order to accomodate slower peripherals. And there is no shortage of fast SRAM that doesn't need any wait states at all.
3. As mentioned SMD soldering is not that much harder if you have large pitches. Ok, the processor is another story but with the right flux it is doable as well.
4. I hear this from a lot of people. My point is that there is simply nothing to debug. Everything has been done for you so the internal parts simply work. Plus, you still can have an inside look via the ZDI debug interface, and this inside look goes much deeper than with the legacy parts as you can see and modify all internal bits and registers.
@@frank-christiankruegel2199
1. True, it's unfortunate that DIP is fading but I totally understand it is not really used outside of DIY/homebrew projects. My FPGA board has indeed multiple SMD components. The main board doesn't because I still want the main board to be usable without the FPGA board (no video, no audio, but there are still UART RX/TX). I understand your point, soldering SOIC chips for me is not a big deal, but this is not the case for all the users.
2. I was not aware of this, thanks for the tip! It makes the external logic simpler then, but it still mean that memory reads will slow down the CPU (it would still be faster than a plain Z80 CPU)
3. Agreed! Not everyone may be familiar with SMD soldering though
4. I will have a look at ZDI protocol. I guess it's a JTAG-like interface, in terms of functionalities.
Globally, what I meant is that an MCU is a black-box. For this current project, I would like something a bit less sophisticated, but for a future Z80-related project, I will surely consider using it!
Thank you for your advices!
I think it's great that there are so many NEW 8 bit computing devices being developed or already available. For example, the Colormite 1 and 2, the Mega65 and the Commander X16 to name a few. It seems there is still a demand for "underpowered" computers that are loaded with personality BECAUSE of their limitations.
Thanks for your comment
This global attraction around retro/vintage 8-bit computers, with the one you cited, mainly Commander X16 and Mega65, had me inspired and motivated for this Zeal project. As you said, the limitations are exactly what I like in 8-bit computers, because not only it also pushes developers to think about writing better and/or less complex code, but also because there are some boundaries: no need to try making the mega-super-extreme-software/platform, the CPU just can't, so it helps concentrating on simpler but working features more than unstable numerous features.
They are also a very good platform to start writing assembly on, in contrary to modern computers, Z80 C compilers don't generate code which is a good as (optimized) handwritten one.
@@Zeal8bit 100% agree! And what gives each old computer its personality are the unique and clever ways that the designers of those systems found to make the best use of limited memory and processing power. For example, by how the Commodore 64 (and Vic20 I believe) uses two side by side pixels to increase the number of simultaneous onscreen colors while giving up horizontal resolution. Or the Amiga's Hold and Modify mode which allows for 4096 colors onscreen at once, but with limitations on _which_ colors can be right next to each other because of how those individual pixel colors are determined. But consoles nowadays have the exact same capabilities: 2k, 4k with 24 bit color using similar processors (or the SAME processor) and loads of RAM. There's is not as much pressure to make the code tight because resources are abundant and processor speeds are high. And, since those games cost tens of MILLIONS of dollars to create, they are not as willing to go out on a limb and try something new because of the possibility of failure and losing that huge investment. This is one of the reasons that there are SO many first person shooters out there.
@@JustWasted3HoursHere Agreed! Several 80s' computers were using Z80 and the AY-3-8912 sound chip, but still I find that they had their own personality as you said. Designers and developers had to be creative. There was one computer that dedicated half its clock cycles to the video processing and the other half to the CPU, but I don't recall which computer it is. That's something you don't really see today anymore. Regarding the Commodore trick to display more colors, do you know if the illusion still works on modern LCD screens?
As you said, I feel like modern computers are almost all identical (I exclude microcontrollers, they are not "computers" after all). Even gaming consoles are just x64 computers now.
I don't mean it's a bad thing though, I mean it's just different.
@@Zeal8bit I'm not sure which computer that was, but doesn't the C64's mainboard split the clock cycles between the 6510 and the Vic-II or something like that? (I think the clock crystal on the motherboard runs at 2mhz while the CPU runs at half that speed.) In any case, the one that had the REAL challenge to make anything happen was the Atari 2600. That thing had only 128 bytes (yes, BYTES!) of RAM and zero video ram: it was almost entirely up to the program's code (the programmer!) to tell it what to draw, when to stop drawing, etc. But this extreme bare metal programming was also its advantage because it gave talented programmers extreme flexibility and allowed the system to last far longer than even the original designers ever thought possible. If you look at some of the homebrew games made for that system in the last 10 years or so I think you would be very impressed!
@@JustWasted3HoursHere I am going to check that !
128 bytes is really tiny, I guess the developers relied on their cartridge's internal RAM.
It's funny that today it's impossible to find such small SRAM, I was unable to find chips of less than 8KB of RAM
i want more videos about graphics and text mode, amazing!!!
Thank you !
More videos are incoming, mainly for explaining software (text & graphics)😄
Love the project! Its coming on nicely
Thank you! It will come even nicer in the next videos with the newer hardware revisions 😄
I2C and SPI are found in the GPIO pins for the Raspberry Pi. Thanks, I did wonder what they were doing.
Un magnifique projet, je m'abonne pour suivre l'évolution.merci
Merci pour le soutien, ça fait plaisir !😄
Very useful. Look forward to the SW updates video
The video about software updates is out! Have a look, I hope you like it
Amazing video. Can't wait for the next one!
Thank you for your support!
It is under preparation😄
You are amazing! Thanks for these videos
Thank you very much!
Wow! 👋👋👋
From what I learned you can do SPI as slow as you want. "John's Basement" has a tutorial on using SPI to talk to an SD Card in his Z80 series actually. But I am also interested in learning about I2C! I think you could also use some kind of DMUX or something so you could use like 4 pins to control 16 devices (or 15, using one value for "none") for instance (+3 pins for MOSI, MISO, and clock); well, it's still a lot of pins.
Indeed, both SPI and I2C can run at lower frequencies, even 1Hz. The main advantage of I2C is the two-wire interface, making it extremely convenient for small devices: sensors, small EEPROMs, RTC, keypad, etc...
As you said, it's totally possible to have a demux, such as the 74HC139, to expand the available I/Os but in any case, SPI would still need at least 4 wires, which is more than what I still had available on the "system port" 😄
But anyone can make an external extension card for more I/Os, we can even find GPIO expander that communicated with I2C, so it means more I/Os while re-using the motherboard's I2C bus!
That is so Feuer! (Fire)
Wow! Very well done. I like the design. Iv especially like the opportunity to learn about the PLD chip. I've never used these. I'm looking forward to seeing more. Great work!
Thank you very much!
PLDs are very convenient, they let you save a lot of logic chips, without adding that much complexity.
You can already check newer videos, the prototype has been optimized.
A very interesting concept. It puts me in mind of my SC126. Do you have eventual plans to integrate an expansion buss like RC2014?
Thanks!
There are three ports:
- System port: for UART and I2C bus
- User port: 8 GPIOs available freely
- Expansion/Cartridge port: gives access to the address bus, data bus, current bank value, interrupt signal, IO/MEM signal
I would say the equivalent of the expansion bus is the cartridge port. The only difference is that it does not present bits 14 and 15 of the address bus, but it has two other signals: EXT_ROM and EXT_RAM (because they are always at the same area in memory)
These can be used as CE signals for RAM/ROM/any chip, making the external board simpler.
@@Zeal8bit The RC2014 buss is more like a hardware expansion buss. Such things as video interfaces, extra ports for serial/parallel devices, etc., can be added to a system via RC2014.
For the FRAM you could get the Cypress Semiconductor FM1808B-SG which is 5V tolerant and 8-bit parallel, Mouser has 11 in stock and expecting 540, so it's still available.
As I mentioned elsewhere, it might be good to do the audio in CPLD to replace your PLA? The CPLD is pretty good at synthesis and feels more like it's in the spirit of your core board.
Thanks for your comment and your suggestion!
I studied this possibility, this was my second choice in fact. Multiple reasons led me to choose the 24FC256 instead: the FM1808B is not available in DIP package (we can still use a SOIC to DIP small PCB though), it would take more space on the board than an I2C EEPROM, it would require a more complex logic. Indeed, it would need to be mapped somewhere in the memory, the most logical choice would be to assign it to a particular bank number: currently bank number 0-31 is internal SRAM, 127-255 is external memory (cartridge/extension port), so we would need 2 banks (2*16KB) number to assign to the FRAM. This would then make the logic more complex. I was also concerned about the way we access it and protect its data. Let's imagine that we set the correct bank number, so it is mapped in the memory, but because of a corrupted or buggy program, the CPU would write garbage to the memory region where the FRAM is mapped, we would overwrite data in the FRAM. With an I2C EEPROM, writing garbage to it is not as easy.
With the price of one FM1808, we can get 8 I2C EEPROM of 32KB, if there is enough room on the final PCB, it would be possible to place multiple ones.
Nonetheless, the main advantage of the FRAM is very fast red/write access (almost 10MHz), compared to the I2C ones. In my case, the software driver can only go up to 130KHz. Which represents about 11- 12KB/s, it is much slower, yes, it means we would need ~3 seconds to read/fill the whole EEPROM, but I find it acceptable for an 8-bit computer, mainly considering that I would like to use it for small files or system settings/preferences.
I would like to add an SD card support in the FPGA in the future, which I would like to consider as main memory.
I totally agree with you that a CPLD is more in the spirit than an FPGA, as I said in another comment, 8-bit computers in the '80s also had CPLD/Gate arrays 😄
When you say "your PLA" do you mean my FPGA? Today, on the board, the sound is managed by the FPGA. To do so, I have programmed 3 PWM channels with RC filters on the output to generate 3 types of wave: square, triangle and sawtooth. As the FPGA does most of the work for generating the waves, the 8-bit programs simply need to specify the type of wave, the frequency and the duration in order to generate the sound.
If using a CPLD, I admit I haven't studied this possibility, do you mean the "big" CPLDs like the Altera MAX?
I don't know if it will keep that sound configuration easy for the 8-bit program, I think it depends on the number of macrocells the CPLD contains? It may be possible by getting rid of the PWM but in that case the software would need to specify the envelop of the wave form with specific timings?
In any case, I guess it also means I need to include both an FPGA and a CPLD, right?
Thanks
You're welcome 😁
Hey I am an EE and wanted a nice project to work on.... I tried to find a web page / site with any of your designs / schematics on it and I do not see any links.... I want to make a Z80 based computer that can plug into a HDMI and boot an old Z80 operating system... (like CP/M) maybe use a Memory card /SD as a disk drive and boot off that as well.... I see the channels you have included on your "Zeal 8-bit Computer" channels list..... do you have any board layouts / schematics available?
Thank you for your interest!
The project is still under heavy development in both software and hardware side, so none has been published until now.
However, feel free to ask questions. Regarding your project, if you want to use CP/M, you should have a look at the memory mapping it requires. For example, the first part of the memory shall be RAM, even the bytes starting at 0.
For the SD Card, that seems doable, will you use GPIOs to simulate SPI interface or will you have an FPGA/CPLD?
Same question for HDMI, will it be handled by an FPGA?
@@Zeal8bit Well the ram is ok as far as the memory mapping will go... the FPGA for the HDMI... well I have seen several projects putting HDMI on commodore C64's I may look at how they did this, but if I do need to do it myself... well I would rather have a FPGA than discrete components
Very, VERY interesting. I have subscribed and wait impatiently for your next instalment.
I am interested in your VGA board design and the manufacture of it. Did you solder the FPGA yourself? I assume it was a BGA device.
Thank you for your time and efforts for us.
Thank you very much for your comment!
Even though this FPGA (EP4CE10) is available in TQFP package, I chose the BGA(256) one for multiple reasons: I find it easier to route, it has more IOs, so this lets me have for example all VGA pins in the same IO bank and finally it would make the switch to another potential FPGA easier (in theory) as they mostly all have BGA variant.
I soldered the board myself, with a hot air gun, BGA is not a big deal to get soldered
@@Zeal8bit I have never air soldered a BGA package before. I have always been concerned as to how to confirm all joints are soldered correctly. Maybe I'll have to suck it up and try. :)
@@peterfielden-weston7560 Honestly I was also concerned about it. After soldering I tested whether there was a short between 3.3V/1.8V/2.5V and GND with my multimeter and then I tested JTAG directly. When the FPGA was detected, I took that for a success 😄
There is a guy who posted an interesting video on soldering BGA chips, he is testing the protection diode which is on each pin in order to check whether the chip is properly soldered. Here is the video: th-cam.com/video/15RFI9wKHq8/w-d-xo.html
I haven't personally tested thought
Hey! Super video! That being said, have you thought about using the DMA instead of manually pushing the bits for your IO? You could use your latches to slow down the 10MHz clk freq and latch the DMA data. Just a random idea, don't know if it applies to your design :) I'll be there for your next video, keep it up!
Thanks for your comment!
Which I/Os in particular are you thinking about? SPI/UART/I2C? Or video memory?
If you are referring to video memory, yes, it would be possible to add DMA to the FPGA implementation, but this would make the FPGA board more complex (need bi-directional level-shifters). Else, it would also be possible to add an external DMA controler on the extension port, Zilog does have one that is meant to be used with the Z80!
The question is do we really need DMA? The most expensive operation I would say is refreshing the whole screen at 60FPS. So each frame must be drawn in less than 16ms. Using the LDIR/LDDR instuction, we can copy 3200 bytes to the VRAM within 6ms, which gives us plenty of time to do something else. This also applies for graphics as we use tiles and not bitmap/pixels.
If what you meant is to have a hardware circuit to implement the UART or I2C bus, that would be also possible but would require a lot more components than using a software implementation.
2 GPIO can make 4 different selections using some logic chips. They make a chip that will take essentially a binary number and raise 1 of x outputs. I believe I saw a video from Ben Eater.
It is possible, you have to use a 74HC139 to do that. But it also means that you cannot have two signals enabled at the same time, which is what you will want to do for most communication protocol (SPI, I2C, ...)
I have not watched the rest of the videos yet, but it looked like the video card connector might allow stacking/daughter board configuration .. ?
Both the extension port and the video card connector allow for stacking as they present all the address lines (22-bit on the newest prototype), the data lines, MREQ, IO, RD, WR signals
Will it be able to load programs from a tape/sound file? (8-bit guy notes most retro computer builds lack different way to get programes into and out of it) and do you plan on making a kit or publishing your files so other People can make it?
That's a good suggestion, I haven't got into tape/sound as I don't have such device (yet?). I guess I could use also a regular computer to broadcast an audio file and plug it to Zeal with an audio jack. In any case, this would require to make an external extension board that would have an input 3.5mm jack. Plugging in to the PIO, this would be the simplest solution.
I don't exclude the possibility of making such a board though, thanks for the suggestion! Currently I have only tested loading files from the ROM (of course), and the UART.
I plan to releasing the board once I fix the hardware bugs and have a stable/usable OS 😉
The reason most of today's retro builds (lol) don't use tape/sound is because of its slow speed and absence of error checking when compared to a fast serial port. XMODEM and a fast serial port beats tape transfer every time. At best you could get maybe 1500 baud with tape. Compared to a 115200 baud serial connection - no contest. Even the bit-banged 9600 baud serial port on a standard SC114 Z80 SBC is a good 6 times faster than tape.
@@SpeccyMan It's true that even with a bit-banging UART, we can reach very acceptable speeds (up to 115200 on TX on Zeal computer)
But in my opinion, the purpose is not only about speed, else we would simply use external flash or even SD cards. It's also about variety of devices we can interface. We can also see it as a Proof-Of-Concept. I find it pretty cool to be able to use a cassette tape to load and store data😄
are you considering offering this as kit?
Thanks for your interest!
Indeed, I plan to sell the motherboard first (not the FPGA board) as kits or pre-assembled boards. I am currently finalizing, testing and documenting the hardware.
Small remark, I am only planning to sell the newest prototype, you can check it in more recent videos 😉
Don’t worry subnautica fans, intel bought out altera in 2015
Yes, but I feel like Intel is slowly letting these "old" FPGAs die. Less and less easy to get.
How to program your own computer without using big techs coding languages?
Not possibble. Evil one owns the world of computers
I am not sure to understand what you mean. This computer can be programmed with Z80 assembly (which is what I use) or even binary if you are a hardcore programmer 😄
No need for any higher-level langage
So you just drop dicrete logic chips and replace them with gal or pal chips. and say it is for simplicity. Because of simplecity is on the first place in your list.
Now consider reverse engineering this stuff. If you have discrete logic chips, you absolutely 100% sure what each ic does. But if you take programmable logic chip you cannot know that exactly it does, without knowing program that is fused in particular chip. It is a *custom* chip. And in-fact it does not reduce complexity of the whole device neither complexity of (low level) debugging process.
The only thing this approach reduces is cost of the fully armed board.
If so, why do you bother with physical z80 and chipset? You already have FPGA that can be fused as z80 and all chipset around it + make proper video output!
That is much easier - you need solder only one bga chip, all other work can be done in software!
Thanks for your interest!
Honestly, it did think carefully before taking that decision of using a GAL.
I am inspired by the computers from the 80s' and if you look at them, they do have such logic chips, you can find Gate arrays (Amstrad CPC) or PLA (Commodore 64).
Yes, as you said, it makes the board simpler, the PCB is easier to route now, all the logic chips generated a lot of tracks. Without making the PCB bigger, it would be simply impossible to add any chip. In fact, on the prototype you see on this and the previous video, I can barely add any track. Adding a GAL will thus reduce the density of the board.
Regarding reverse engineering, I get your point. The fact is I plan on documenting these GAL, how they are programmed, and what each pin does.
If one still want to reverse engineer them, well, I don't think it would be hard (for this board of course, not in general). Not only you will see that the output pins are used as Chip Select for other chips, but also because of the memory mapping I showed before and the ASM header files that will clearly state the address of the I/O chips.
For debugging, it is simpler with a GAL than will all the logic chips, why? Because you only have one chip to test to check your signal, and not 4 or 5 anymore.
Last thing about this, they are reprogrammable, with the TL866 II !
So changing the memory mapping is possible for who wants to 😁
This is why, in my opinion, getting GALs in my case is worth it: more advantages than drawbacks. It is not necessarily a cost reason.
For the FPGA, you are also right, it could replace everything, but where would the fun then?
I use the FPGA for the chips that don't exist (anymore) or not manufactured anymore. This is the limit I give to myself. In my opinion, you can't compare an FPGA and a GAL, a GAL is still easily programmable and understandable. An FPGA is a real huge black box, and that is much harder to debug.
I appreciate that you gave me your opinion on this. I am not saying I took the best approach, nor that I took the best choice, but I simply take the approach that corresponds the best to this particular project. I may choose another way to do (logic gates only) for other projects 😁
@@Zeal8bit Thanks for your detailed answer. I hope that your projects will not be only just for fun, but will be useful at least for your own experience and, if it helps someone else' advance in their researches it will be great!
Perhaps a CPLD could not only replace the 8-bit logic but also provide the audio synthesis?
@@user-yg6tr1wm6x Thank you! I am having a lot of fun, I also hope it can help others 😄