That sounds like an awesome pick up. I would love to build computers based around all of those ICs. Unfortunately I know next to nothing about the 80xx series of CPUs. That's one reason I went with the Z80, because I had some past experience. My advice would probably to start small with something simple. Try to find an existing project design that you can copy. If you have any specific questions I would do my best to try to help. But bear in mind my knowledge is probably not that much better than yours. If you go to my channel page and click the little arrow to expand the description you will see my about page where you can view my email address. Feel free to drop me an email.

Similar, but not the same. Mine uses the TommyProm design which can be found here: tomnisbet.github.io/TommyPROM/

@@SteveRaynerMakes thank you

I assume you mean RobCap and ElbowShaftGear. These are only held together with glue. I imagine I used superglue.

Checkout the description in part 10 for all the links .

Each part has it's own version number. My notes can be found here: inmoov.civrays.com/build/shoulders

Hi thanks for your comment, it's nice to get feedback. Yes you are correct, the clock is too slow so we need to hold the reset line low for longer. The problem is we don't know what speed the clock will be running at, also we might be in single step mode. We need a proper solution that will count the number of clock cycles and hold the reset line low until we have seen about 4 clock cycles. I've seen a nice solution for this, but never got round to implementing it. I really should have put in a solution right at the beginning of the project.

Steve if you see the ZX Spectrum 48 k is using a pull up resistor with 220k value and a 1μF capacitor and the clock is at 3.5 MHz so the capacitor is small but the resistor is big that is make the capacitor to charge slowly so the reset line takes more time to reach the 5V. I do not remember the plus 2 A or plus 3 what values they are using but I can look at the schematic when I go home

It is to prevent key ghosting. This is when a key appears to be pressed when it is not. It is caused when several keys are pressed at the same time. The diodes prevent the electrical current traveling backwards to another column through a pressed switch.

@@SteveRaynerMakes thanks for explanation.

awesome.

Ah, rookie mistake. The most dangerous things are the things you think you know, that ain't so. Naturally the stack post decrements, that's only sensible. Except it doesn't.

thank you, much appreciated

It's still there. I just need to motivate myself to continue working on it.

I would say that if your microcontroller operates at voltage of 2.2 to 3.6 then, no, you do not need the level shifter. This will simplify things for your design. The 10v is just a maximum rating for the physical connector. Not something you need to be concerned about because I doubt you would find an SD card that operates at higher voltages. But in theory anyone could design their own cards that operate at any voltage. So it's just the connector designer telling us don't use anything over 10volts.

No, my one does not seem to have the option of connecting a larger screen. The font size is very small and I have seen other people complaining, but I don't think the font size is adjustable.

This would have been cool to use on the 8088 to address palette entries or sound channels.

Yes it's a good idea and something I have thought about. There isn't really that much need for the CPU to read from video RAM. We also never need to write to ROM. However from my memory of making games on the Z80, I would often read from video ram to know what was on the screen at certain points. Usually for collision detection of the player. That would make me think I would need to retain a duplicate of the screen data in normal RAM. It is a nice idea though. There are a lot of scenarios where we never need to read from Video RAM.

@@SteveRaynerMakes yes I thought about this too, but doing collision detection this way is very time consuming and if you do paint you sprites and background bitmaps all on one plane you probably would want to read back from vram anyway for proper masking. For fast flexible game graphics in an 8 bit system I would either implement at least two independently scrollable layers: background probably as tiles/multicolor text like the c64 but double the resolution and a color bitmap overlay where I paint my sprites without having to extensively mask out existing graphics at the same time. Colission detection can now be done by the layer compositing logic of the video circuit which can capture the bitmap counter position if both bitmap and background have pixel values than 0 (or any other value in a comparison register - depends on the complexity one would like implement)sprites to sprite colission can be detected while writing to the vram by reading the value first in an register (done in hardware) and comparing the byte to be written with the old one. If bits are different and different from 0 it would be a collision. Both would trigger an interrupt where the game could do its thing then.

@@0toleranzalready before the NES games actually had a background. This made the collision detection in C64 useless. This is why you need a z ordinate or even two playfields. Z can be encoded in the palette, but I hate palette. Give me RGB 332 direct cokors. Z buffer in n64 is on a different page to not slow down Video DMA. On Jaguar it is on the third phrase. I propose deferred rendering. First draw each sprite into one of the 8 bit per pixel and check for collision. Then replace with the winner sprites color. Can even do translucency or “shadow sprites”.

thanks

Thanks. I can't take credit as I took the idea from someone else's design, but it's good to know that this is a tried and tested technique. I really feel that I have learnt something very important and useful here.