I was never really gone, but I should be able to get more videos out over the next few months. I have the broad strokes of a plan for the rest of this year.
Missed you, James! What a great video to return with, loved every moment. As a C64 boy, I can even forgive the use of the Spectrum! In reality I've become quite keen on the Z80. Love the UART application.
Thanks James! A fascinating video delving into the ‘Speccy’s’ mysterious edge connector. I grew up with the ‘Speccy’ and share your fascination with the innards of these revolutionary first generation 8 bit home computers. A recent search of my elderly parents attic confirmed my worst fears that my own beloved ZX Spectrum + had been given away many years ago! 😢
Hello, I'm glad you back on Speccy Thema. Sorry I didn't respond earlier. You don't really need to distinguish between read and write if you dedicates a specific addresses for specific operations; like one address for write parameters, and another for read results. I mean if we(you) are still thinking about "coprocessor" expansion into ROM slot. To make expansion direct on edge connector from speccy will be easier for sure :-)
I really like the idea of extending the functionality of old machines by changing what they interface with. A while back I was working on a project to make a SNES controller out of a block of wood by using some conductive ink for touch sensing and having a microcontroller translate it to SPI for the SNES. I think I still have it laying around half finished somewhere.
Well you're right, I didn't consider that. Doesn't really matter for a temporary breakout like this but I'll try to keep it in mind when I design something more permanent with an edge connector.
I know this is quite an old video by now, but for anyone watching in the future: flux will help with getting the solder to properly flow and not just bead up on the surface. There's a tiny amount in solder wire, but not enough to prepare those large surfaces.
@@weirdboyjim That's certainly true! I've spent plenty of time cleaning up leftover flux with alcohol and a close-cropped brush. Situational for sure, might help enough to be worth the mess on something like this edge connector. Love your videos, inspired me to implement a close analogue in verilog to run in simulations to really understand what's happening at the lowest level of CPUs.
Ooo. I'm currently on episode 30 odd of the CPU build, after watching the VGA build. The computer now is much smaller, less blinkenlights, a keyboard... And a familiar sounding name..... I look forward to discovering how James makes this 'zx spectrum'
Wow... I must have missed it last time... "top marks" to whoever put the Spectrum edge-connector stuff into the EasyEDA library! So nice to have fiddly jobs done for you by somebody else! I'd expect to see everyday stuff in there but Spectrum add-ons aren't exactly what you'd call "mainstream" - excellent work whoever you are. I'm also, finally, impressed with Sinclair BASIC... when you did `LEN a$`, I said "nope, you need parentheses on that function"... ... ... and you didn't. When you indexed into a string like it was an array, I was all "No way! This is the 1980s! That won't work!!!"... ... ... and it worked. As a long term Speccy detractor, I'm now like "oooh! That BASIC's actually quite good".
Yeah! That was handy! The spectrum basic is an odd beast, the method of typing whole keywords seems weird at first but once you realize that's how it's tokenized in memory (rather than being stored as text) it makes much more sense.
Your irritation while routing may have been alleviated by using the auto-router. It definitely would've been an easy design to check over after it completed. Just a thought. Great job, by the way. You have one of the best channels for learning about hardware around.
Living in a broke-ass EE country at the time, I nonetheless somehow managed to pester my parents into getting me a local ZX clone (a CIP03) and managed to miraculously source a gorgeously red QuickShot II joystick (that thing had _autofire_ ffs!), but had no way to connect the two. There were precisely zero ways to buy an interface or at least the relevant edge connector. But the actual circuit of a Kempston adapter was a piece of cake for my TTL-savvy young self, and the logic ICs were actually available locally (with some effort). So I hand-sawed a bunch of long thin comb-like fingers (for individual flex) with the right spacing into two pieces of PCB, drilled two holes and soldered a short piece of stripped copper wire into each finger (as "the contact"), then bolted them to each other facing inwards with a third piece between them that spaced and keyed them to the key slit in the extension port. Needless to say, the pucker factor on the first test of this _very_ DIY interface was indescribable - I was intensely aware that if I short or hog the CPU bus in any way and damage the Z80 I'll NEVER get a second ZX... but it worked fine. For years and years. Good times...
It would be cool to see some new spectrum games making use of cartridges, as the cartridge could do somethings the mappers did with the NES - like auto-cycling through graphic definition table every frame for parallax scrolling effects, per-scanline animation, DMA blitting etc :) Obviously it would have been prohibitively expensive back in the day (the speccy was my first computer) but now a custom "ROM" cartridge is obviously much cheaper :)
The Spectrum has bitmapped memory in RAM. The NES used a tile table located in the cart, usually ROM. So that's how mappers could do tricks like that. For the Spectrum you can only alter the screen by reading and writing to the RAM. Even if you had some separate circuit, rather that doing it on the CPU with software, you're still limited by how quickly you can write to old RAM chips like that. So that idea would be difficult to get up and working, at least much more difficult than on the NES. The tiles in cart ROM meant the NES didn't need tile RAM, so was quite a lot cheaper to make. The downside was that each cart needed 2 separate ROM chips, CODE for the CPU, and CHAR for the PPU. They had their own bus each which is why the NES's cart connector was so enormous. Overall it was cheap, and made games at least twice as expensive as they had to be for other consoles. The Master System did it the usual way, and had much better graphics, so there was no advantage to the design other than money. "NES-expensive" is a term that should be in the lexicon as much as "Nintendo-hard" is! ALL 8-bit systems had difficult games, it's not a Nintendo thing. But as ever, it's how the Americans had things, and they're in charge of the language apparently, including slang. See also the "Videogame Crash" which only happened in North America, and only affected consoles.
@@greenaum yep I’m aware of how the spectrum worked - I wrote enough software for it 🤣 I’ve also written an NES emulator along with others in my spare time… Although different there is the possibility of greatly increasing the potential using a custom cart: DMA transfers. By halting the Z80 and copying from ram in the cart to display ram which is much faster than the usual method of popping from the stack into registers then pushing into display RAM. Handling sprites and a tile map based display in the cartridge which will be pushed to the display ram without the need for the z80. Other effects such as pixel scrolling etc which again would be handled in the cartridge and then DMA’d to the display ram. Yep it’s different but there are. A lot of possibilities 🤣
Thanks Mr. James Sharman ... You have returned me back to my old memories with ZX Spectrum 35 years ago ... Those were the golden days dealing with micro systems not now ... Can I ask if you have an academic degree of Electrical Engineering to start all from the beginning ?
Interacting with the spectrum is a bit scary in some ways, I would be worried about something connected to the port potentially damaging the machine, maybe if you do a revision you could add some buffer ics to it to help isolate it a bit.
When I was kid I had this crazy idea of using the audio cables you used to save / load to audio cassette to network two spectrum together. Possible but it would have taken up all the cpu's focus to either send of receive.
Just an idea: An easier way of soldering the connector might be going with a thicker PCB. 1.8mm of even 2.0mm? Question is off course, will it still fit in the connector.
Unfortunately that would be a problem for the edge connector the other side. I wondering how think I can go, I have a similar problem to solve elsewhere that idea may be more suitable for.
@14:30 Umm...the clock does stop, every time there's a CPU access to contended ram. That might explain both the unusual shape of the wave, and the clock rate discrepancy as well. However, I know very little about oscilliscopes. There is no crystal on the Spectrum, true, the clock generator is built out of gate array elements on the Ferranti Uncomitted Logic Array.
The ULA does have control over the clock going to the Z80. What it does is to drop the clock signal whenever it needs to access the screen memory in the lower RAM to ensure that it rather than the Z80 has control over the bus going into the 4116 chips. Part of the consequences of this can be found in the custom loader software used to DRM protect later Spectrum games. The code for these loaders was always ran in the upper RAM because the process of interleaving memory access and instruction fetches with the ULA's fetches meant the timing of the lower RAM could not be guaranteed making a loader coded in this space less reliable.
It was with the ZX, messing with some game in MONS (as one does), that I encountered my first anti-debug feature ever... I was staring at the screen in disbelief at the code writing a constant into a register, then immediately reading it back and comparing it to another value - wtf, how can this ever succeed...? Then the little lightbulb went on above my head and I just laughed my ass off: the register in question was the R-register, which gets auto-stepped in hardware, and if you were step-by-step debugging you sure as hell didn't read the same value back as if the code was executing continuously. Trivial to bypass once one understood what was actually supposed to happen...
@@AttilaAsztalos Ah, yes. That was the second version of something which I think was called "Speedlock". I wound writing a program that automated the process of modding the decoder to get to the loader. Ended up that I could crack those in a few minutes!
Glad you liked! No, these are very distinct projects. I used the UART for this as it was just more interesting to connect something I built myself than show led’s lighting up!
There is a waste operation in the calculator, that writes to location 0. I noticed that because my old zx has 64K ram. At startup the orginal rom was copied in to lower 16K. At some math operations location 0 to 8 was changed. Changed this waste routine to dump somewhere else.
@@weirdboyjimI`m sure I read in the ZX manual when I was a kid that the IN OUT functions were controlling the interface pins. I might have to have a utube search. Would of been nice to know what we know now. I was just playing with Triacs etc making disco lights with a 555 timer and old tape desks. I used a decade counter chip to switch between lights. Then add ZZTops lol.
@@weirdboyjimSome of the Basic compilers for the Speccy had it too. Such a luxury! Many was the time when as a kid I had to manually go through changing all the line numbers (-:
Could you not use 2x Data Latches for the Address Latch and output the ....... LD HL,(ADDRESS) LD DE,(PORTADDRESS) LD A,L OUT(DE),A INC DE LD A,H OUT(DE),A RET
I'm using memory writes rather than I/O ports because at least some the lines I need are exposed in the cartridge. There is some really weird stuff in the IO range of the spectrum that was done to save cost that I didn't want to fight.
Perhaps my wording was poor. I always had a set of pins that had every output from the expansion port in the order they appear on the edge connector (That was easy to route). The bit I removed was an extra set of address and data lines that were reordered numericaly (That was would have been difficult to route as many lines swap over). In hindsight I wish I had spent the time to route the extra set, it would have made the testing step smoother.
If you were adding connection points for every single pin then yes it would make sense to add every pin label but, as you haven't broken out every pin, I agree with not adding every label.
I have to admit I was under time pressure when I made this board or I might have been a bit neater in a bunch of areas. If I had known how much of a pain it would be in both wiring and video editing I'd have put a bit more work into the PCB.
@@FrankGevaerts Comet o think of it, interfacing it is the easy bit. Making some code to play music on the spectrum would be time consuming. Maybe I should just work on the Audio circuit.
@@weirdboyjim Maybe... I'll admit that my motivation is that I want to do this myself (although maybe on an RC2014 instead, or both, as I have an RC2014 backplane with Spectrum edge connector...), so you finishing the audio circuit far enough to publish everything would help :)
@@weirdboyjim Back in the day I hooked my 48k up to a line printer and wrote a program to calculate Pi - outputting to the printer, it went through a box of tractor fed paper. I also made a UPS as I was forever forgetting to save my listing. The last project I made controlled the ignition of my Dads car and heated up the interior for a warm journey to school. I have moved on to the ESP32 range of boards now as they have a lot more power and versatility and a lower cost of entry!
You can see the memory fading away with this little program: For example user definded graphics become distorted. ORG 29000 LD SP. 32767 XOR A LOOP: LD R,A JR LOOP END this keeps the the R register at 0 preventing the complete refreash cycle.
@@weirdboyjim The lower 16K is refreshed by the ula, the upper 32K by the Z80. You can not run this trick in the upper 32K because the program is fading away.
@@weirdboyjim bit 7 of the R register can be used as a "general purpose output" - the Z80 auto increments R each instruction but it wraps back to 0 after 7F rather than FF. You can manually set/clear bit 7 and by decoding the refresh cycle you can then latch it into a flip flop or similar.
