You said data shehts sound like she-its. If you know what I mean. She eats in one word... sheets.

what ram and logic chips did you use for this

AS6C4008 for the RAM, which is 512KB big Logic chips are just OR, AND, NOT gates (74HC32, 74HC14, etc...). In the latest revision, I use a PLD

thank you for the help. @@Zeal8bit

Thank you! You can check newer videos to see the advancement 😄

Thank you for your feedback and your support ! I will do my best to provide regular updates on the projet, with better video quality. When I started this project, I realized that nowadays we have a lot of online resources, accessible hardware (logic analyzers, oscilloscope, etc...), and services (PCB making) to start such project. So I would say: follow your dreams! 😄

Thank you very much and welcome aboard! I admit it's the graphics that motivated that much to make this project come true.

Thank you very much 😁

Thanks for your comment, I'll make sure there will be an easy way to program in assembly on it!

@@Zeal8bitAwesome! Can you share the Schematic and PCB file?

@@quanzhou3414 Thanks！ The project is still under heavy development, a lot of big changes occur frequently

He should make a commercial product that is sold similar to the 8-bit Guy.

​

Thanks ! You can check the newer videos to check the new memory mapping. It's backward compatible with the one in this video but even more versatile !

Thank you! I am, you can check newer videos, there is even a first release available !😄

Thanks for your comment. The Osborne was a nice machine, it supported CP/M! you can check newer videos to see the latest prototype.

Honestly, with patience and time, it's all possible! Thank you for subscribing, I hope you'll enjoy the next videos!

Thank you for your support! A new video will be out soon. I did learn a lot thanks to this project, I hope I can share this with viewers

@@Zeal8bit I will try to look out for the new video. I subscribed, so I have a better chance of seeing it. I love how you can slot together the two revision boards. It is a great idea, as one board might get more improvements faster than the other. Thus, you can swap out boards, as opposed to having to replace the whole affair each time. This is a really good project, and I really hope you can create something that is as good as the old machines, if not better.

@@horseradishpower9947 I will do my best to reach this goal! You got the point of having two boards. Currently, I am more concentrating on the mainboard, I can update it without changing the FPGA one. And the fact is I don't really want to solder an FPGA as often as the CPU board 😄

@@Zeal8bit I understand your efforts, as I put together my desktop computer with a Raspberry Pi 4B as the main piece. As a result, I have an appreciation for this project. And what you are doing is brilliant. I suspect in the next year, you will have gotten this project together, to the point where this is more finalised. It would be interesting to see if this could be made to run things like office packages, because that would show that this machine has greater utility. And would stop the average person from thinking that this computer is just a toy of some kind. Again, good luck with this project.

Thank you for your support !

Thank you for your support! No worry, I still have a lot of things to present in future videos 😄

Thank you ! 😁

Thank you very much for your message! You can check the newer videos a lot of things improved on the latest versions of the motherboard. CP/M is very interesting and a lot of Z80 fans are still using it!

Thanks! Indeed I tried to not have a deep look at what was done in other Z80 projects to make sure not to inconciously copy😄 Dead Z80s are a pain, not because of their price but because of the amount time they make you waste! Moreover, as you experienced they don't really "do nothing", that would be easy to guess they're dead, but they actually have a behavior that may look ok. In my case, my dead Z80 was ok for the first few memory access. So when using a logic analyzer, I didn't directly see something was odd: the first clock cycles were ok. When I saw that the IOREQ line was never low, I started thinking about "what if it is dead?". It was my first time working with a Z80, I was still a beginner at that time😄 Now I always buy multiple samples of the same chip, just to prevent such issues

Very nice project! I also wanted to use the AY-3-8912 for the sound, which is well-known and often used back then, but it was only available as used unfortunately. I wanted to stick with new parts. I am curious about the reason you are using an STM32 to inject code in RAM, is there any practical reason or limitation for not adding a ROM? Or was it by choice?

@@Zeal8bit Thanks for responding! Yes, these AY soundchips are just available as used parts.... ...mostly delivered from China. However I’m apparently a lucky guy who never had any problems with these parts. All of them I've ordered worked... ;-) I recently ordered some “Sound synthesis” chips - the SP0256-AL2 (these has been used in the late 80s as an Extension Module called “Currah MicroSpeech” for the Sinclair ZX Spectrum - and this chip worked like a charm. ...Then I applied these more powerful OPL2 FM Sound-synthesis chips (e.g YM 3812 as used in the Sega Mega-Drive and Sounblaster Cards back in the late 90s) and none of these caused any trouble... But anyway, I can understand your decision! Why the Solution with the STM you've asked. Well, I decided for the architecture with the STM because of the benefit just to use the Z80 assome sort of "rapid development system". So the STM on the other end is connected to my Mac via USB (CDC). So I’m able to (re)program the Z80 System quite quickly with the STM acting as a “Gateway”. Furthermore - since the STM has full access to the Z80 Bus-/ Data- and Control Signals and even generates its clock I have full control over this part. With this architecture I’m also able to “Inject” Instructions “on the fly” (by driving the databus depending on the Z80 MEMRQ/RD and perform slow clock / single steps and let the STM “watch” the whole Z80 Bus while letting the Z80 execute each (intrusive) Instruction / Data ... ...and let the STM then report all Z80 System Bus activities back to my development machine via USB... Furthermore the STM side consists to a 8MiBit SPI Flash, a quite small I2C EEPROM (for parameter Setting) and a littele 0,96" I2C OLED Display with some Pushbuttons... This setup allows me to store some Z80 code in the SPI FLASH which then I may recall in order let the STM "reinitialize" the Z80 attached SRAM as discussed... So this System should be treat more a quite flexible “live” Development System with a direct Connection to my Development machine. ...Or maybe considered as an “intelligent Real-time Z80 debugger” ;-) BTW - You decided for discrete 74xxx logic for the Glue-Logic around the Z80 Adress decoding etc. Well, I was challenged by the same issues but I've realized this by using a GAL 20V8 device (Programmable Gate Array Logic) which substitutes all of these discrete parts into one single device... However I like your work and the great presentation! Keep in being curious! 👍👏 Best, Peter from Munich, Bavaria 🍺

Thank you for your comment! A lot of things have evolved since, the memory mapping is even more versatile now. The 64KB are split into 16KB pages. Each page can be mapped to anywhere on the 4MB of physical address space! Feel free to check newer videos

Thank you !

Thank you very much! You can check newer videos to see the latest prototype 😄

Thank you very much!

Thank you very much!

Thank you! You can check more recent videos to see the hardware updates ! 😄

Thank you, it means a lot!

Thank you very much, this is very motivating! I already have some ideas for the next videos😉 Out of curiosity, what is 8bit newsletter?

Thank you! A new video is coming soon😄

@@Zeal8bit That's great to hear! Can you tell us more about how you got started in electronics and how did you gain enough knowledge to pull this off?

​@@rafalocity Sorry for the delay, the new video is out now 😁 Roughly, it all started at university, when one of the project I had to do was designing a 16-bit CPU in a Logisim. (digital logic circuit simulator) I got really interested and curious about it. After university I started my career as an embedded software engineer, so this is at this particular moment that I really started learning a lot about SoCs, microcontrollers, RTOS, schematics, etc... On my spare time, I was then attracted by FPGAs as they let me apply all the knowledge I learned with Logisim, so I learned Verilog and video protocols such as VGA. Meanwhile, I was more and more attracted by KZfaq videos about retro-computing and retro-technology, as I didn't have such 8-bit computer when I was younger. At the beginning of this year I discovered that getting a Z80 CPU and such chips is really an easy task nowadays, so I read some documentations, the datasheets, also watched so videos online. It is incredible how many documentation is available online for the Z80 (and related chips, such as the PIO), that really helped me! I also have some friends who have a pretty wide knowledge about all these retro-computing topics, giving me advises, tips on electronics, etc... To sump up, I would say that my embedded software engineering helped me a lot understand the architecture, the way it works, the implementation and the organization of the project. I still had to learn by myself the remaining required technologies such as Verilog or more advanced electronics. Again, internet is gold mine for this.

@@Zeal8bit Please continue! I had my start back in the early 80's with the TS1000/ZX-81, and learned Assembly the hard way. Graduated to C64 and PC Clones. Haven't stopped learning since. It's fun watching videos like yours rebuilding the old capabilities in 'current' hardware. Makes me want to break out the TS1000 under my bed to get back into it, not just the Emulators out there...

@@kevinshumaker3753 Thanks for your support Then you must be a master in Z80 assembly! Get back to your TS1000, I find that real hardware has always a different feeling that emulation😄 I wish I had such computer when I was younger (which is also one of the reason I am making this project)

I am happy reading your comment! I hope you will reach your goal, no matter if it's a Z80 or a 6502, the experience you'll learn on the path will be valuable for any architecture

Thank you so much! Although I am still designing this thing on paper, I already have a good idea of how all the circuitry needs to work. Maybe in the future il even design my own processor!@@Zeal8bit

What I also like in the Z80 compared to the 8080 is that it only requires 5V power supply, no need for -5V or 12V. The Z80 makes memory manipulation very handy indeed! Do you happen to know what are the additional 2-3 registers used for? For example, one cycle of LDIR when BC is NOT 0 takes 21 cycles, composed of 4, 4, 3, 5 and 5 T-states (according to the user manual). The first 4, 4 is an instruction fetch because the instruction is 2-byte big, the following 3 cycles is a memory read at address HL, then the 5 cycles are memory write to DE (while incrementing DE and HL?) and the final 5 cycles are for decrementing PC I guess. As I understand it, one register is needed to store the value read from (HL), could it be that there is 2 8-bit registers to buffer DE's value while it is being incremented?

Thank you very much!

Thank you very much !

Thank you for your comment! You can check newer videos to see the latest prototype 😄

Thanks for your comment! Only 44 macrocells? That's a nice achievement! Was it a PAL or NTSC signal? Do you have an article/blog where we can read more about it? I am also convinced it's doable to do it with 74xx logic chips, I even think it's possible to generate a 640x480 VGA signal out of 74xx logic chips. However we would be limited to text mode, for graphics mode, it starts getting tricky 😄 In both cases, you either either need dual port RAM or you'd need to slow the CPU down to give it clock cycles to the video board (to let it read RAM) It'd be a nice side project though, even if not very convenient for real usage.

@@Zeal8bit PAL. Source code: github.com/jxsvoboda/tvsig Videos: kzfaq.info/get/bejne/payArblz3t-xpJs.html Blog: jiri-svoboda.blogspot.com/2010/10/one-two-three-testing.html jiri-svoboda.blogspot.com/2010/11/faster-than-speeding-panda.html jiri-svoboda.blogspot.com/2010/11/nuts-and-bolts.html jiri-svoboda.blogspot.com/2010/12/moment-to-remember.html

Hello Wolfgang, what a pleasure to see you here! The machine is still under development, I hope I can finish it as soon as possible and have you test it! I can't find the comment either anymore, I thought it was moderated or something like this. Very strange... I am going try posting it again. EDIT: Same thing, the comment is not appearing, maybe you have to manually approve it in your "held for review" section?

Thank you very much, you can check newer videos to see the latest prototype 😄

@@Zeal8bit So I did... WOW! These are great improvements! So you also substituted the SN74xx Logic into a GAL. 👏👍 Great Project with great progress! 👍🍺

Thank you very much! I did replace the logic with GAL, it makes debugging the logic glue much simpler and it takes less space 😄

Thanks, you can check newer video to see the latest prototype

Thank you !

Thank you, good remark! I meant that it should be simple from a user/developer point of view. Using an FPGA in this case does help abstracting a lot of things. This is why the interface to write characters or tiles is pretty simple.

谢谢你，你也可以在B站看，我在那发布有中文字幕的视频😁

Thanks !

Agreed! You can plug a probe to the pins and actually see what is going on in the hardware! Was the Z80 card meant to have CP/M on 6502 computers?

@@Zeal8bit Yes, that was the main purpose. You could run Visicalc (not important to me) and Turbo Pascal (very important for me). But while I programmed the 6502 in assembly language, I never tried to do this with the Z80 (to many opcodes).

Thank you very much! You can check newer videos to see the latest prototype 😄

@@Zeal8bit Of course i will! :-)

The Z8000 is not compatible with the Z80 unfortunately, so that would mean the whole OS would need to be adapted and ported, including the user programs. While it is possible, it would be another project in itself. Also, I noticed that the Z16C01 CPU is discontinued, it's not easy to find it brand new, correct me if I am wrong. The latest revision of Zeal 8-bit OS, supports no-MMU computers, so it would be possible to run the OS on the ZX Spectrum, the TRS-80 or the Amstrad CPC.

Thanks for your comment! I presented a newer prototype for the motherboard in later videos, that I consider being the Release Candidate. It still have a few bugs but I corrected them on the version that I consider final v1.0 one. So, from a hardware side, this is almost ready. From a software side, as you can also see from my latest videos, it's also moving, I published the open-source OS, Zeal 8-bit OS which will be embedded on it. I also developped an emulator for the board, very helpful for debugging and developping. You can find both on my Github: github.com/Zeal8bit Finally, having a board without any documentation is useless, so documenting the hardware is something I would like to do too before releasing it. This only concerns the motherboard, not the FPGA board which will come later as it needs more testing and development.

Thank you for your comment ! In my second video, I show the CLP I am using for the latest prototype, it saves so much space on the board 😄 Any reason why you ended up not finishing it ?

@@Zeal8bit, well the main reason was the cpld I chose. I have to use a weird parallel port programmer on an old laptop running windows 7. It's an Altera cpld on a plcc package. I'm kind of rusty in hdl and simulating the peripherals I was intending to add (namely, an spi port for an sd card and the banking registers plus the banking logic) took too much time and I just switched to another project (this one uses an Intel 80c188 cpu and doesn't need that much glue logic).

@@cocusar I met this issue: I wanted to use an Atmel ATF1500 but unfortunately, it is not heasy to find a programmer for. So I will be using an ATF16V8B (ATF22V10B may also help me save another chip), which can be programmed with the TL866II plus. you could also use an FPGA for the peripherals. Or, you could also do an SPI driver in software with GPIOs (but that would be slower than CPLD/FPGA) I am not very familiar with the 80C188, is it the successor of the 8088? How are you going to manage the SPI/SD Card/Banks with it?

@@Zeal8bit Yeah, I could use an fpga but I had this cpld at hand and it has an eeprom inside so it was a pretty convenient thing to replace all the logic and additional peripherals. So the 80c188 and 80c186 are mostly the same as the 8088/8086 but they contain some peripherals on the cpu itself. The address bus is 20 bits wide, so you can have 1MB of ram+rom without the need for banking. In my case I've used a 512k flash and a 512k ram. If more ram is required, then I could bank that on a specific address, exactly as EMS memory was used on the 8088/8086 PCs. The cpu has an interesting peripheral, which let's you control some pins as general purpose chip selects, so you can program some registers and say "from 0x300 thru 0x400 and if it's an IO access, the use the /GCS1 for it"; really convenient! And for the spi/sd, these GCS pins can also be used as gpios, so it was a matter of fiddling around and creating a bit banged algorithm. I ended up porting the ELKS project to it, which is a linux-like OS. really cool project if you want to tackle an 808x or 80c18x project in the future. they also use a gcc compiler for thr intel 16 bit cpus, so it's almost as programming modern-day apps!

@@cocusar Thanks for the info! I didn't know this processor. The 20-bit address like is really convenient, I have also seen some 24-bit lines on some CPUs. Does the 80c188/6 implement this with an MMU ? Or can you address any 20-bit address through the code without configuring the memory pages? Form what I understand from what you tell me, it has an IOMUX as peripherals to change at runtime the purpose of a pin, that's pretty advanced for an old CPU. Do you have any blog/website/videos to show your project ? I would love to follow your progress

Thanks for your comment! Indeed, not on only designing the PCBs took time but also debugging once soldered 😄 The fact is I modified my memory mapping for several reasons, including having a better software compatibility with already existing systems. Now, the memory is split into 4x16KB pages which can be mapped to any 16KB page of the 4MB physical address. This also fixes the problem of the VRAM being write-only. I made a video where I explain this, I also ported CP/M to have a try and it worked: kzfaq.info/get/bejne/o9GPdqeZu5imiXk.html For MSX, the problem is the hardware, as the standard states that the CPU must be running at 3.58MHz, the video processor needs to be a Texas Instruments TMS9918 and the sound chip a AY-3-8910. It would be possible to emulates these in the FPGA but that would be a completey different project. (It is also possible to make an external board which embeds these two and connect it to the extension port)

@@Zeal8bit Nice to see your next video. Compatibility has it's benefits, especially if you want other people to follow and have a community around your computer. I'd recommend to use some standard monitor /*I use WozMon from AppleII - terse and small*/ to use standard converters/tools to work /* copy & paste in terminal for example*/. Is the mapper MSX compatible? I recommend to try port MSX DOS - it's quite CPM compatible and it supports FAT12 filesystem - easy to transfer files. There are projects for drop in replacements of AY and VDP in FPGa, for AY even STM32 or AVR based. MSX can have faster CPUs, they are syncing with fps on VDP. With faster CPU it's possible to 'emulate' VDP and AY spending CPU cycles wasted for waiting H/W readiness to perform actual operations. 'emulation' can be performed in NMI handler for AY&VDP ports I/O. It's enough to make h/w compatible enough to make 'emulation' fast and efficient. Screen resolution, color numbers color palette must be compatible. For the sound just have 3 sound channels with sine/square/saw + 1 noise + volume control for all channels is enough to make 'same' music in the games. /*for demos it may be hard without having exact emulation on STM32 or FPGA*/

The Z800 is not produced anymore, it is obsolete, which makes it harder to find, mainly in brand new condition

Indeed it would be possible to use a microcontroller instead of the FPGA, it would even simplify the sound generation and the SD card interface, for the VGA output however, it may be a bit tricker but possible. The fact is I am a software guy at first so using an FGPA, programming in Verilog and making a custom PCB for it took me out of my comfort zone😄

...or implement the (Z80?) CPU among all other peripherals within the FPGA ? ;-)

Thanks for your comment! I do know about the Commander X16 and its VERA FPGA. That's also a very nice project. Technically, I think it would be possible to use a VERA chip with Zeal 8-bit Computer, the video connector is a parallel port, it has the address and data lines, and also the RD/WR/IO signals. From a design point of view, it's my FPGA project that motivated me to make this project at first, I would like to make it work, and complete the features without making it too complex. The VERA is very powerful, too powerful for my use. It has so many sound channels and graphic layers. Yes, it makes it possible to make very complicated graphical softwares, but I find that this is a bit overkill for my computer. I often think about the ZX Spectrum, its graphics had limitations, but it still has some good gems! The attribute clash made the charm of the computer. In any case, once Zeal computer is finished, anyone will be able to plug anything to it, so VERA chip is a possibility!

고맙습니다！Thanks for your support! 😄

Alright, I will😄 Thanks for your support!

Indeed! The Z80 was very popular. Some Ti calculators are still using them nowadays (+ an ARM co-processor nearby). It would be interesting to try porting Zeal 8-bit OS to the Ti 86 or MSX computers!

Indeed, if we look at the instruction set, it looks more like a 8080: no IX/IY, no alternate registers, no complex memory instructions (LDI,CPI,etc...) But for the chip itself, the ASIC, **my guess** is that it's based on the Z80. Because at that time, Sharp was already manufacturing Z80 CPU clones, logically they would take this base to make their new chip, the LR35902, used in the GB. It's just my thoughts, not sure if that was really the case😄

Thanks for your comment! As you say in my later videos, the mapping has been changed to something more versatile. Small notes on the former mapping though, the ROM part also included external ROM part, which means that if you have your game/program on an external cartridge, it could be mapped at 0x4000. Regarding video, you also saw it in a later video, the tile engine will be upgraded to have a sprites mode too. So we would have text mode, simple and fast, and graphics mode, supporting background tile and sprites. In my case, a bitmap mode is not possible unless it's a 1-bit mode (maybe 2-bit if I optimize the VRAM space). And there is not DMA, so getting a decent framerate may not that simple either. I still believe it is possibe to achieve nice things with tiles + sprites, just like the Gameboy did. For the sound, I wanted to use parts that are still available today (not refurbished). I was unable to find any. I understand that would be better for compatiblity to try emulating a former one. But for simplicity of programing maybe not. With the FPGA, a good amount of things can be abstracted. My sound module simply takes the note frequency, the waveform (triangle, pulse, sawtooth), a (n optional) duration, and that's it. In any case, your inputs are really valuable for me for the project! It's great to have another programmer's external view on it, it means a lot. I first hope ot finish the project, even if it's not perfect nad has flaws. I don't want to make a super-overkill-mega 8-bit computer that would take 3 years to complete. I have already spent a year on it, I would like to have a first final version. Hardware upgrades and optimizations can then come in a second time.

@@Zeal8bit Thank you for the kind words! SOUND.I know current situation is still bizarre but it should be possible to get Yamaha chips. I know YM2151 was chosen for another project mainly for availability reasons. VIDEO. As I suggested in the other video, you problems comes because you try to fill real 640x480 pixels. If you work with 320x240 and then double that internally, many new possibilities will open. On 8 bit CPU Bitmap mode is used primary for nice artwork like title screens or to overcome the limitations of tiles, like pixel precision. A full screen 320x240x8bpp image takes "only" 76kb, there will be room even for sprites ^_^

@@SquallSf Thanks for the tip, I am going to check the YM2151 ! Good to know! I wasn't sure what was the best approach for choosing the resolution but supporting both will solve this question I guess

What are you using for the graphics ? An FPGA, a dedicated video chip or another MCU?

Define “decent”. You really have to lower your expectations unless you are a wizard with electronics.

I think it always helps, it give you very strong basics, but motherboards today and more complex. Not only because of the amount of components, but also because of the speeds (GHz!), and the complexity of the CPU itself. In any case, it's always good to have good basis in this domain and understanding an 8-bit computer or CPU does help

I did have a look at this one and at the AY-3-8910, both are very well known chips. The AY-3-8910 even has two I/O ports. I saw on the SAA1099 datasheet that the maximum clock frequency is 8MHz, mine is 10MHz, I wonder if that would cause any issue. But as you said, they are not manufactured anymore, so currently I would like to stick witch new parts. However, it is possible to make an external card embedding that chip as the cartridge/extension port presents the data lines and and IO address lines.

Very good question! It was a bit hard for me to keep the video concise, simple to understand so without giving too many details. In my mind, the tiles are the 16x16 pixels images that we can show on screen and a sprite is the value pointing to one of the 128 tiles. (128 tiles take 32KB, 1200 sprites take 1200 bytes) What you said is correct, the tilesheet/tilesmap indeed takes 32KB. The thing is we can tell the video chip (the FPGA), what we want to map in the first half of the memory, with a single OUT instruction. Thus, if we map the tilesheet/tilemap, the 32KB describes all the pixels of our available tiles, but if we map the sprite ram, we can then modify the tiles that are shown on screen, so make some animation, movements, just by modifying 1 or 2 bytes. The sprite ram is organized as two 1200-bytes "arrays", the first one starts at 0 (from 0x0 to 0x4AF), the second at 8192 (0x2000 to 0x24AF). The first one represents the background, the second one is the foreground (both share the same tilessheet/tilesmap of course). The foreground is a bit special: it supports transparency. The palette is the standard VGA palette (Mode 13h). It cannot be modified, so it is not mapped. This was for graphic mode, in text mode, only the sprite ram is re-used. It is separated into two 3200-byte "arrays" (we have 80x40 characters on screen). As explained in the video, the first one, from 0x0 to 0xc80, is for showing the characters themselves, but the second one, from 0x2000 to 0x2c80, is used for colors. Indeed, text-mode supports 16 colors for both background and foreground. So one byte in the second array represents both background (high nibble) and foreground color (lower nibble), this was designed like this for performance reasons. The palette used here is also the VGA palette, but in 4-bit mode, and is it hardcoded in the FPGA, so it cannot be changed. I am using a Z80 clocked at 10MHz, filling the first 32KB of memory takes 69ms when using LDDR or LDIR instructions, which is reasonable in my opinion. I mean loading the required tiles is not something that will be done a lot of times, or at least, not all the 128 tiles each time. Similarly, loading 1200 bytes into the sprite ram takes about 2.52ms with LDIR or LDDR. Plus, the FPGA supports writing into its sprite RAM and tilesmap RAM at anytime, regardless of the VBLANK or HBLANK. Regarding the resolution 320x300 is not a VGA standard resolution. 640x480 is the smallest possible resolution, but I imagine it would be possible to simulate a 320x240 resolution by duplicating the pixels. This would let us have 20x15 sprites on screen (16x16 tiles). I haven't thought about it yet. Finally, about the interrupts, on older computers/console, it was required to wait for V-Blank or H-blank to draw modifying the video RAM, but in my case here, it is not required as the video ram can be modified at any time. However, I still plan on having these interrupts for two reasons: prevent flickering when moving sprites around and mainly timing. I don't have any timer on the board, I don't have any plan to integrate one so having both interrupts will help a lot to determine how many ms or us have elapsed. With a 640x480 resolution at 60Hz, we would get one V-Blank interrupt every 16ms, and one H-blank interrupt every 32 us. I need to make another video presenting these features with more details and with some demos. I hope it was clear, feel free to ask if you have any question.

@@Zeal8bit don't worry, I know how hard it is to make videos. What you did is awesome. Thanks for you answers, I think I mostly get it, so get reading for my second round of questions :-) I got that you can page the VRAM using an OUT, so the 32K limitation doesn't really apply. I still have some troubles with your terminology: for me a tileset is a description of the graphic of 128 tiles. It takes 32KB. A tilemap is a description of a full screen of tiles (sometimes a little more, with some hardware registers to offset x and/or y, giving the possibility of hardware scrolling). It takes 1200B (as they are limited to the screen and just contains the ID of the tile, with one bit left). There are 2 tilemaps, the foreground having transparent tiles, (maybe via a hardcoded key color in the tile?). What I am still missing is how do you intend to position stuff. In my vocabulary, a sprite also have an x,y coordinate, but tile don't, as their position is implicit. ie: I don't get where those positions are stored. On the resolution piece, I was thinking of pixel doubling + black bars (or 320x240), just so the amount of data is small enough to be managed by the Z80. But, at 10MHz, it isn't a big problem, although the limited address space will make it difficuly to work with all the data. But that's part of the fun, right? Another direction is a 640x400 BW image (wich black bars). That's better than the original Mac, you could do a fun GUI on that (but you need to be able to read the VRAM for many operations). On the VBL piece, I wasn't thinking of stuff like avoiding snow effects, but to sync (ie: telling the FPGA that the developer is done with presenting a screen), and scanline interrupts to potentially hack (ie: if there were one day multiple palette, you could do more than 256 colors). Of course, if you don't have timer, a VBL of some sort is indispensible, in particular as you have sound (those days I am coding on the early macs, which only had VBL for tracking time -- see my channel for the result :-) ). Keep on the excellent work. I wish I had the ability to do such a wide ranging project, but my hardware skills are too limited.

​@@fredsretrocoding1421 Thank you Fred! I understand your confusion, indeed, there are a tileset of 128 tiles of 16x16, so 32KB, as your said. There are indeed 2 tilemaps, your terminology suits better the architecture I made. The thing is sprite's position is determined by its index in the memory, this is why in my terminology, both can be interchangeable (kind of). This is valid for both text mode and graphic mode. Thus, the top left background sprite is represented by the byte at address 0x0, the next one is at address 0x1, ... until 0xc7f. As there are 40 sprites per line, the sprite at line i and column j is at index 40 * i + j. It also means that in order to move a sprite on screen, you need to write its value to its new index/position and erase it from the previous location. This layout makes it convenient and simple to render games or programs based around grids. I also chose this layout because of the limitations I have on the FPGA itself and its board. As you said, the challenge of working with all the data is fun! I mean, today with our +1GHz embedded systems, we tend to concentrate less on low-level optimizations. The CPU/SoC architecture is often not even part of the optimization equation when writing C/C++ software. I don't even mention any higher level programming language. regarding reading the VRAM, I agree this may be a problem in GUI based programs but this is also why I choose to have this much RAM, I mean 512KB for an 8-bit computer is more than enough for most programs. You are right, I am hoping people will be able to hack Zeal board to make it impressive! I remember hearing that in the '80s, some people where using the h-blank interrupts to simulate a multi-color background on the Commodore 64 and related computers. I am currently designing the next prototype of the board, integrating both vsync and hsync interrupts. The fact is the FPGA is outputting a 16-bit color signal to the DAC converter, before going to the VGA connector. Thank you for your support, I hope you will enjoy this project. Honestly, no matter what skills you have already, you can always learn more and more and figure out things by yourself. Nowadays, we have so many resources available online, for free. As we say in French, on apprend sur le tas! 😉 (Between, I checked your video and they are outstanding! I would love to see how you achieved this in a video)

​@@Zeal8bit It was indeed a terminology issue. What you do is between a graphic mode and a 40x30 text mode with 128 16x16x256 colors with customizable characters. I feel the lack of true pixel-addressable sprites will be an issue, as the only way to have pixel precise drawing will be by hacking the sprites, like we used to do with VGA text mode characters en.wikipedia.org/wiki/VGA_text_mode#Cursor (replacing the 4 characters under the mouse by 4 custom chars with the mouse drawn at the right position in it. Possible, but cumbersome). > Honestly, no matter what skills you have already, you can always learn more and more and figure out things by yourself. Nowadays, we have so many resources available online, for free. A vintage graphic card on an FPGA has always been something I thought about. I even got an Mojo FPGA dev board to learn, but I just didn't have the time to invest into it. But I probably have enough software projects to keep me busy forever... > I would love to see how you achieved this in a video I still have to make a video for the release of the new version, then I may do a video for the nerds on the "how it is done". Long story short: C++ pre-encoding, 68k assembly and a lot of stubborness :-) [ note: the github is available github.com/fstark/macflim ] Allez, super boulot, j'espere bientot une video sur la suite! Faut pas hesiter a entrer dans les details... edit: fixed url formatting

​@@fredsretrocoding1421 You described it well, then I haven't implemented real hardware sprites, as there is no true pixel-addressable graphics. But after thinking about this, I think it would be very interesting to have sprites, it would be possible to replace the second layer, the top one, to have 64 or 128 (or even less) hardware sprites instead. So the first layer will still be addressable the same way as today (i * 40 + j), and would thus be used as a background, whereas the top layer would be gone and simply replaced by N sprites that, of course, are on the top of the background. As you said, having something like a cursor then would be much simpler to implement, no hack-workaround required. As you may have guessed this will be a long work so I may postpone this to later, but I keep this idea! I would like to have the hardware stabilized for now. Mastering and getting familiar with FPGA takes time, mainly when having a software background. I think we all have the same problem: more cool projects than free time. Thanks for the link to the repo, and I look forward to watching your next video. Merci beaucoup pour ton soutien!

Merci beaucoup! J'ai fait des vidéos plus récentes dans lesquelles je présente le prototype le plus récent. Qu'est-ce que Z8 OTP exactement ?

@@Zeal8bit un Z86743 je pense merci

Thanks for your comment! I plan to sell few samples as kits or assembled units very soon (only the motherboard to begin with). Stay tuned!

Thanks for your comment! I am an embedded software engineer, so I already have some knowledge about digital electronics. For the rest, I read some books, articles, blogs, watch videos to learn about Kicad or even electronics basics. Overall, it always ends up like: you want to do something, you don't know how, you search online, you get some resources, you try, you fail, you retry, until you get to your goal. As long as you have patience, you will reach your goal.

Haha thanks for the compliment! I would say that the purposes of the two projects are different, I am trying to keep the computer simple, compact but interesting (and extensible). I am not trying to make the ultimate 8-bit computer that would fit all purposes, with a lot of sound channels, a lot of graphics capabilities, etc..

This was the first design. It has been changed since, you can check newer videos 😉

Thanks for your comment! I love that you give your opinion, that's the purpose of my videos, exchanging ideas with people 😄 The thing is I was working on this yesterday (I was looking at CP/M)! I was so wondering whether I should change the mapping to a 4x16KB page (64KB virtual memory address). With this, we would have 4MB of physical memory address space. This has multiple advantages, as it makes the system memory pretty flexible. However, on that case, I am also considering forcing the last 16KB to RAM. This would be used for system stack, interrupt vectors, global variables, etc.. The drawback that I see is that it complexifies the system in the sense that it is less straightforward for the users. I explain, in the case of the VRAM for example, today we know it's always mapped to 0x0000-0x7FFF, but in the case of the MMU (4x16KB), the user himself has to configure this. Well, it's simply an OUT instruction but still, it's less straightforward. I am going to have a try soon 😄

@@Zeal8bit Well I am careful with comments usually since some people seems to be extra picky and angry if someone comments anything which is not 100% of the opinion the video says as well, regardless with my good intent only. I think universality is always good, I wouldn't bother to have forced fixed memory area at the last 16K, in fact it just makes thing more complicated to do. Surely you are not forced to ever change the last 16K if you want so, but it's always nice to have the possibility who knows about future software projects on your SBC would need that. I cannot say now by heart, but some two pieces of 4x4 bit register file 74xx (a 4x8 would be better, but IIRC there is no such a thing or hard to get?) IC would be about enough, being A14 and A15 from the Z80 is the register selection, and the output of the register file is the new system address bus A14-A21 (surely you need to solve the problem to write the register file as well). Any modification here, like forcing last 16K "page" to be fixed just more complicated at the hardware level, so honestly I wouldn't bother with that, and it's even better to have the possibility at least. One key problem however that reset state is problematic, since most of these register file ICs does not have RESET. Other than that, you can use the constructed 22 bit address but topmost bit to decide selecting ROM and RAM, if it's OK to split the 4Mbyte address space into ROM and RAM as 2-2 MBytes. For video memory, hmm, yes, honestly I would just take normal RAM can be read/written as well (so you need to map in ...) but your FPGA solution need to sense the write to the area dedicated as video RAM and update its internal block-RAM (I suppose what you do ...) to be able to generate video signal from it. Using I/O to access video RAM is kinda slow, maybe OK for some projects, but problematic for really neat things like for SymbOS (unless your video solution knows some fancy things like "executing" video copy inside VRAM etc, what it SymbOS also do in MSX where the video RAM is not directly CPU mapped either).

@ Oh I understand, some people may be irritated, yeah. In my case, I find that very informative, not only for me but for everyone reading, we can study multiple approached😄 Anyway, I started analyzing this possibility this morning, seems like I will be able to test it on my current PCB without too many modifications (few wires to add, no need to cut traces, that's acceptable to me) Indeed, my board already presents two 74LS670, which are 4x4 bits registers. This is what I used for banking, and this is what I am going to use for mapping. This will give me 22 bits of address, so 4MB physical address space. I am not worrying about the startup/reset, I already have an idea about how to do it. I do have a RESET line for the CPU. On startup, this line is LOW for few (several) cycles, so that's what I am going to use. So anything related to reset or fixed memory page can be managed by the ATF16V8B. But as you said, first it would be more straightforward to forget about the fixed memory. No worries about the VRAM, I decided to allocate 128KB of physical memory space, that should be more than enough currently. Indeed, it is not fixed to 0x0000-0x7FFF, we would need to map it to anywhere within tht virtual address space, just like other memories. Well, that's acceptable in my opinion. I will try to start tweaking the hardware tonight to include that MMU implementation 😁

Your comment is true if you want cp/m compatibility you need 64 k ram 32k might just work but you wont run any useful programs. The way to achieve thks is to have a minimal (2k) boot rom which is switched out after it starts to boot cpm

​@@alynscott2109 This comment is a bit old, I made a lot of progress since😄 The latest has an MMU of 4 pages, 16KB each. It's more than enough to have a small bootloader for copying CP/M into RAM and executing it. As you said, 2KB is enough, but making the pages 16KB big was the simplest (less components too). You can check my more recent videos

Haha, good point! I also believe it was not a genuine one. In any case, having multiple copies of the same component is always handy, in case one fries (mistakes happen) or for the sake of comparison in another circuit.

Thanks for your comment! There are bidirectional 3.3V/5V level shifters on the FPGA board for the parallel bus

ALynx 301?

Oh my bad, for some reason I thought you were referring to my custom FPGA board, which I presented in later videos. The Alinx board I am using in this video doesn't have level shifters indeed. I did the level shifting on the motherboard with 74HC4050 ICs. Since that takes quite a lot of space, I moved them to the custom FPGA board after that.

Haha, did you use to do similar project?

@@Zeal8bit lol. no... it's a simpsons joke where woody allen is writing fortune cookies in a room with a bunch of chinese people and homer comes up with a fortune of his own. someone says, "this guy's like a young me" and then i think it's woody allen says, "young me? this guy's way better than yung mi. yung mi is a total hack compared to this guy!"

Oh I have watched that episode! But in French... The translation of that joke is bad, they completely changed it😔

Thanks for your comment! Indeed these are nice successors, I also like to eZ80, I will consider using one of them for future version(s) 😄

Thanks for your comment! The OS is still under heavy development as the hardware changing quiet often. For graphics and text, I will make another videos (with examples)

There is no such instruction on the Z80. There are two ways of doing it if you want an immediate value: - ld a, 66 and ld (0xc7f), a - ld hl, 0xc7f and ld (hl), 66

I agree that PCB revision should have had more, this was my second iteration, it is pretty dense. You can check the newest hardware revision in my latest video 😄

烧录器是在网上买的。其实挺好用的，支持很多不同的芯片，也可以在Linux用！

Thanks for the suggestion, I have never heard of it! I am going to check its specs. I find that Z80 computers globally the same, they have RAM, ROM and logic glue. What makes the difference in my opinion is the memory mapping they choose and the video chip.

@@Zeal8bit And what do you think about building this computer?

Thanks for your interest! The project is still under heavy development so they aren't available yet

Is the (Z80) source code or a disassembly of the game available online somewhere? If yes, it is possible to port it and run it

haha, that would be possible actually, but that would be anoter (very long) project

Zeal 8-bit computer is now compatible with CP/M, you can check newer videos 😄

@@Zeal8bit The question still remains is it available assembled. Thanks.

It is now compatible with CP/M, you can check this newer video: kzfaq.info/get/bejne/o9GPdqeZu5imiXk.html

TempleOS is a 64-bit OS, not 8-bit

Я принял это решение, потому что было проще всего взаимодействовать с чипами, требуется только позаботиться о контакте Address15. Но это был первый дизайн, текущий дизайн имеет MMU, благодаря этому мы можем отображать ПЗУ и ОЗУ в любом месте на 64 КБ памяти. Проверьте последнее видео для более подробной информации

Thanks for your comment! I see the FPGA as a huge CPLD, (Complex Programmable Logic Device), in this sense, you cannot compare it with a CPU/MCU. But some will also tell you that you could make a CPU out of an FPGA, and that's right. I highly recommend you to watch the newer videos to see the updates out the board. Anyway, the FPGA board is not mandatory to run the computer. The motherboard has now a UART input and output, which makes it usable without the video card board. You could even imagine making an extension board which relies on an old video chip. About the simplicity, I was talking about the simplicity to use. Of course the PCB design would be complex and difficult to come up with, but this is my part😄 What I meant in the video is that I want to make a board easy to use/to program for. And indeed, as you can see in the video, writing data to the video card is fairly easy (1 byte per char/1 byte per pixel) Finally, regarding the ROM, I ended up making a "universal" MMU which has 4 pages of 16KB, so that the ROM, RAM, VRAM can be mapped in any page.

In theory, if this takes off, the fpga board’s functions could be baked into an asic and related components on a revision of the main board.

Thanks for your comment! You are right, one should be careful with such platforms. I would also add Mouser to your list of official retailers. These 3 are the best places for new chips.

Indeed, I am NOT using any MCU (PIC, Atmel, ...) in this project. I am however using an FPGA for the video part (as a VGA video chip). I explain this at 5:19 😉

If the FPGA board is not connected, the board still works, I have now implemented a UART interface for communication as a plus. As I said in the video, video chips are not made anymore. Thus, if we don't want to use refurbished components for making an acceptable VGA graphic output, not only text output, the only solutions we have here are: - Use an MCU (ESP32, Atmega, STM32...) - Use an FPGA - Use a powerful CPLD (I guess that you would also consider using that as emulation) - Use another ROM/RAM and logic chips only dedicated for generating a simple VGA signal, without hardware sprites. I am not even talking about sound here. I would like to point out that using a second Z80 responsible for VGA output is not a viable option as we need a 25MHz pixel clock for 640x480. So, as you can see, in order to have an interesting project, one has to make some choices. Plus, I would like to add that I never said that I was trying to make the cheapest 8-bit project. Anyway, I would be very happy to hear your ideas on how to handle VGA graphics/texts and sound, without software nor hardware emulation, that would help me😉

What a thoroughly rude and unnecessary comment.

@@SpeccyMan Nah, that is the usual Internet guy who has just realized that there are people out there actually doing something instead of fussing around. Oh and if they grasp that others are actually smarter than them, they switch into full blown "entitled Karen-Mode" (as demonstrated up there). Why not welcome this little self-embarrassing piece of absolutely royalty free real life comedy? You want popcorn?:))) Zeal8bit: Well done!;)