View unanswered posts | View active topics It is currently Thu Mar 28, 2024 11:41 am



Reply to topic  [ 10 posts ] 
 Z80 game console 
Author Message
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 74
I rise from the dead, and this time with a project that made it further than concept!

For a while now i have wanted to make a Z80 based game console, and it went through several iterations each with different features and form factors. I have ended up with this little guy:

Attachment:
20210419_225207.jpg
20210419_225207.jpg [ 4.78 MiB | Viewed 1810 times ]


This was the first iteration of my console, all the other fancier ones never actually worked. So i went back to this original one since it actually runs code and works "properly." I put that in quotes because there are still a few bugs to work out and to finish the operating system.

Specs and features are as follows:
    Z80 CPU at 8 MHZ (although the chip is rated for 10 MHz, i only had 8 MHz oscillators)
    32KB SRAM
    32KB ROM
    Graphics, Sound, and IO handled by an ATMEGA1284
    Monochrome Composite video at 120 x 96
    Mono sound
    Games ran from SPI cartridges
    Controllers use UART (this mean controler ports can be used for general serial comms as well)

Now some of you may think there will be problems with trusting graphics, IO, and sound all to one AVR microcontroller, and you are right to think so. Back when i first designed this board i thought it would be fine. Now that i'm working on it again I want to go back in time and slap myself for thinking this was a good idea.

The main problem is there is sever bus timing issues when the Z80 needs to read from or write to the AVR. It takes an entire 2 milliseconds per transfer, and that's because i have to put in a 2 ms delay or else the AVR doesn't actually read the data bus. I blame this to shoddy bus handling code, and i will have to redo it with inline ASM and interrupts so the AVR can service the Z80 as fast as possible without dropping data.

Another issue that hasn't shown yet but i'm sure will once i finish all features, is the speed of the AVR. Handling graphics calculations, Sound calculations, and handling IO will surely put a strain on the AVR core, which means i will have to optimise the hell out of my AVR code. I may even have to rewrite the entire thing in assembly if i can't get C to work well. Next console I will offload at least the graphics to an FPGA or CPLD with a custom core to give whatever microcontroller i use for support a break.

As for the operating system, it will be very basic. It will have a simple ROM monitor, will load games and programs from the cartridge port, load programs into RAM from one of the serial ports, and flash cartridges with programs from serial or stored in RAM. The ROM monitor isn't functional yet, but i have successfully gotten some characters on the screen:

Attachment:
20210419_222706.jpg
20210419_222706.jpg [ 1.49 MiB | Viewed 1810 times ]


I hope to post an update to this project once i tackle those bus timing issues and get some simple programs running!


Tue Apr 20, 2021 6:15 am
Profile

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 74
Why not VGA? I mean, for the "next" thing :D


Tue Apr 20, 2021 11:49 am
Profile
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 74
DiTBho wrote:
Why not VGA? I mean, for the "next" thing :D


I mean in my next design I was going to have it use VGA internally then have a converter change it to composite so I can use both! My main reason for wanting to keep composite is so I can use these on regular TVs


Tue Apr 20, 2021 9:46 pm
Profile

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 74
I did something similar with a small FPGA to have a VDU. A text display module with vertical scroll.
Nothing special, but I needed it in a larger project.

In my case the CPU is a softcore embedded with the FPGA, nothing special, it's a very small CPU without any particular features, and without any hardware multiplier or divider, it's simply the most minimal possible, but it has the VDU attached as device with the 50% of the BRAM used for the text-video ram, the other 50% is for the ROM and RAM.

I need to redesign it. I have never played with Z80, so I am curious and interested about this project :D

What did you use for the PCB? EagleCAD? KiCAD? Protel? OrCAD?


Fri Apr 23, 2021 8:12 pm
Profile
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 74
Quote:
What did you use for the PCB? EagleCAD? KiCAD? Protel? OrCAD?


I use KiCad for all my boards. I'm a sucker for free open source software :lol:

Quote:
In my case the CPU is a softcore embedded with the FPGA, nothing special, it's a very small CPU without any particular features, and without any hardware multiplier or divider, it's simply the most minimal possible, but it has the VDU attached as device with the 50% of the BRAM used for the text-video ram, the other 50% is for the ROM and RAM.


I have something similar to that in mind for my next build. I plan to implement a type of simple GPU which is really just a simple CPU core attached to some VRAM and video generation hardware. All i need the core to do is simple tile copies, nothing too fancy

I do have my hands on an old MIPS R5000, sometime in the future i hope to get that running with an FPGA running a 3D GPU core. But baby steps first!


Sat Apr 24, 2021 5:42 am
Profile

Joined: Sun Dec 20, 2020 1:54 pm
Posts: 74
Ah, MIPS ... I have many many stories about that :D

edit:
sorry for the OT. Deleted.


Last edited by DiTBho on Tue Apr 27, 2021 6:41 am, edited 1 time in total.



Sat Apr 24, 2021 10:30 am
Profile
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 74
Man the things i would do to get my hands on a proper MIPS dev kit. And i should look into that PS1 hack one of these days.

But before we get too off topic, an update on the Z80 console!

Changing the GPU bus handler to an interrupt based one solved the bus timing issues, now accesses to the GPU are only a few microseconds. Still painfully slow for the Z80's 100 nanosecond accesses, but it will have to do. Next up is to make the ascii tile sheet so i can get a hello world program running!


Tue Apr 27, 2021 6:00 am
Profile
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 74
So i'm still investigating random crashes due to bus errors, and a thought just occurred to me. It may not actually be timing issues, but rather bus signal integrity issues. But im not sure if that would be an issue with something like this. Has anyone else had signal integrity issues with older hardware like this?


Mon May 10, 2021 6:25 am
Profile

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1780
We've certainly seen issues with poor power supply routing and inadequate decoupling, and we've seen problems with unclean clock signals. There's a whole new set of possibilities if mixing TTL and CMOS logic levels.

On a heavily loaded or long distance bus, there can be issues. Famously Acorn's BBC Micro has a set of pull-down resistors, purely as an empirical fix, because when Steve Furber put his fingers on the bus the thing worked better. That's a very overloaded bus.

Hold time violations can be tricky to track down.

And sometimes, yes, there is switching noise. If all the address lines change at some point, that's a bad time to sample data. Usually it's best to avoid sampling data except on the clock edge.


Mon May 10, 2021 8:30 am
Profile
User avatar

Joined: Thu Oct 08, 2015 11:57 pm
Posts: 74
Hmmmm I'll have to investigate any possible electrical issues then. It's weird though, i have found it's not the Z80 that locks up but rather the AVR chip. And it only happens at start up, if it starts fine then the system works flawlessly. But 1/10 times the AVR crashes on startup and keeps the Z80 in reset (since it manages reset as well).

This board is a little messy and is slightly damaged with a few bodges, so a board redesign is in order. Hell, the 5 volt regulator is missing a leg so i have a wire soldered directly to the metal exposed from the corner of the package missing. Maybe I'll take that as an opportunity to switch from a software based support chip on a microcontroller to something on an FPGA or CPLD. At least to take graphics operations off the micro so it can focus on IO and other things. A good 70 to 80% of the AVR's execution time is dedicated to graphics operations, leaving little time for anything else


Tue May 11, 2021 12:12 am
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 10 posts ] 

Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software