engineers@work

This it the twenty-dollar question! My aim is to place the designs/software onto git and it will be open source and people can build as they like. If some Chinese manufacturer got involved they would be very cheap as they are common parts but for 5 off assembled it was costing me ~50GBP each. PCB+parts from Mouser to self-build work out around GBP20, but this is paying top dollar for <10 parts.

@engineerswork1 Awesome, now where can we buy them?

@r0b0t_sp1der Yep, just busy putting all into git (minus the plethora of temp files)! Probably this w/e or Easter and will be up on git.

@engineerswork1 Oh - are you going to put the Kicad files up online?

I've done both and if I could have got an FPGA small enough with enough BRAM and ALM's, I wouldnt have thought about using the RP2350, glad I didnt as it is a nice device. I would imagine you could keep redcodes Z80 emulator for an 8080, Z80 is a superset, just need to rewire the PCB for the pin differences and change the PIO's, 2 PIO's sampling the clocks and setting IRQ's which other PIO's pickup to activate the bus cycles. On my website are past FPGA replacements for the Z80 which work well but they are well oversized and more tailored for the Sharp machines! My last board, eaw.app/tranzputer-fus… is still waiting completion, just need to get a fab to make me one as my own reflow build had many bad bga joints and trying to use a hot air station to fix just compounds the issues.

@engineerswork1 Awesome, thanks dude. I'm torn. I'd probably learn _more_ doing it this "emulation" route than just with an FPGA. But it should just be a pin scramble and some code ...

Yes, I've published the schematics and documentation at eaw.app/picoz80/ and will soon put the whole software/hardware repo up on git. An 8080 would probably be a bit of work, the pins are in different locations and the clocks/multi-voltage may be tricky, a bit like the pico6502 Im also working on for clock phasing and the multi-voltage shouldnt be an issue as reading the specs, the outputs are >=0v. 8088 should be very possible too, as would the muxed 8086.

@engineerswork1 Astonishing work. I was noodling around with something like this, but for 8080 and TMS9900. Maybe via FPGA. But when you have 200Mhz and the PIO, pretty much don't need it. Are you going to release the designs? It _probably_ would work as a pico8080 or pico8086 already ...

The logic thresholds for TTL is 0.8v or below = 0 and >2.0V = 1 - thus driving at 3.3V, so long as the motherboard of the host doesnt have very long PCB lands or many attached devices, you could drop to 2.3V and still see logic 1. Input side is the same, the RP2350 will see 5V as logic 1 which is > 2.0V so fine and < 0.8V as logic 0. This article gives you a good insight: hackaday.com/2016/12/05/tak…

@engineerswork1 How 40yo devices handle 3v3 signalling without level shifters? I know Pico is at least partially 5v tolerant, but can't emit that.

Documentation on my projects updated at eaw.app - now includes a Japanese version, translated courtesy of Claude. Working with Grok for over a year, now switching to Claude due to primary work requirements, I must say Claude is very good. Grok is excellent but not being able to view your code repo or update it is a major limiting factor that I hope xAI address. Claude has its issues, you need to be topic and programming aware to correct oversights and mistakes, but I hope to use AI more in the future to enhance and further my projects.

It is certainly possible to add ICE functionality, just time! I think the best method would be over a web browser, CLI would be easier to implement as it would operate directly within the RP2350 and finer control but Web based would be more user friendly. Will give it some thoughts.

@engineerswork1 Wow, I had a very similar idea in my head for quite some time (but not enough spare time to actually execute it). My main motivation was what @gojimmypi asked about, though - in-circuit emulation / debugging.

New version of picoZ80, v2.5 - adds a USB hub to enable direct connection with the RP2350B and ESP32. Documentation now at eaw.app/picoz80 - MZ700 persona all but complete, tidying up code base before moving onto the MZ-80A persona.

Thanks. I’m not familiar with the ZX ULA but you could virtualise it as a driver in the codebase. Passing through to physical for core ram and the extended request intercepted within the RP2350 and routed to/from internal PSRAM, the physical wouldnt see a bus cycle (except a Refresh cycle if needed). You would create a 1:1 map of the ULA state and registers internally via write through and then decide in the code wether to access physical hardware ram based on this known state. On a 1K ZX-81 it would be easy by just adding the ram via json config, but once you start using custom banking then it needs to be done via a driver which is host aware, hence the concept of persona’s such as the one I wrote for the MZ-700 as it too has internal ram banking.

@engineerswork1 Cool project. Is it feasible to "port" this project for ZX Spectrum, including mem/io emulation? It could serve e.g. as upgrade from 48k to 128k as well. I see some specific issues: ULA accessing (possibly emulated) RAM and partial I/O ports decoding in ZX (for emulated I/Os).

Refactor in this case as Ive built the project from blocks of my other tranzputer designs and need to make it uniform. The RP2350 code was originally C++ with C hooks but after some heavy debug sessions and need for speed, converted it all to C. The ESP32 is in C++. I also used Grok for some of the PIO work to ease the learning curve and my experience with Grok has been 2 steps forward (wow, look what its done), 1 step back and a lot of hard debugging! Currently working with Claude, will see how it helps and how many bugs it introduces in code factoring!!!

@engineerswork1 @psxdev Every time I hear the word "refactor", I envision this loosely knitted sweater... with just one thread dangling... that gets pulled a little. And then a cartoon disaster. Lol. I'm super happy that Visual Studio and other editors have such robust rename and refactor features!

I currently use gdb connected to the SWD port of the RP2350, core 1 runs the Z80 so it is possible to place break/watchpoints and see the Z80 state/memory. It would be possible to add some kind of interpreter running on core 0 connect via the USB to issue commands/set break points but this would need development. Also possible to develop a web based interface via the ESP32 to set/debug the Z80 on the RP2350. Will keep it in mind, at the moment just concentrating on getting this project to an initial completion state where I can publish on github and others can adopt/enhance as needed.

@engineerswork1 Any chance to have a single step debug, breakpoint, JTAG like debugger? Perhaps the RPi debugger would work for this? But to get it to recognize Z80 instructions... Hm

@Denysko_Bublyk The picoZ80 was initially developed in the RC2014 Mini at 7.37MHz. It runs at 8MHz fine, I dont have any test machines which exceed this speed (yet!). QFP though, not sure all the parts would fit without going oversize!

@engineerswork1 Next step is qfp version and up to 20 MHz support

In due course, yes. I have a BBC Model-B and Master I want to use the pico in and was advancing the 6502 version on an Apple I card roughly in-line with the picoZ80. They share a common code base for the ESP32 and the RP2350. I hit a snag down to dry joints, chasing bugs which were poor soldering, so suspended the pico6502 and concentrated on the picoZ80 and getting it fab assembled. I will shortly do the same for the pico6502, make it 6512 compliant with DBE so it will sit in either the B or Master.

@engineerswork1 Is there 6510 version?

@psxdev Thank-you. The repo will be put into github shortly, I’m working with Claude Code to refactor and once complete will place on GitHub.

@engineerswork1 Amazing job. Is project repository already public?

@ZrzkyKock Hi Zrzky, In due course I will place onto github, I want to get to a finished state first with the MZ700/MZ80A/MZ80B/MZ2000 and perhaps the Amstrad PCW.

@engineerswork1 It's great Philip! Can I expect the docs for this project to appear on GitHub as well?

New version of picoZ80, v2.3. No longer dependent on a Dev module, it uses an ESP32S3 with 8MB Octal PSRAM, 8MB Flash RAM and onboard antenna. The Octal PSRAM increases the speed of web page rendering. RP2350 now upgraded to A4 version. Power lands thickened and additional reservoir capacitors added, the earlier version saw the occasional brownout on boot. Optional USB added for ESP32. Design routes ESP32 debug output via the RP2350 which routes it to the default USB, but for tricky debugging, the additional ESP32 USB/JTAG helps a lot. Software has advanced on the MZ700 with the addition of new virtual drivers:- MZ-1E05 Floppy Disk Controller MZ-1E14/MZ-1E19 QD Controller MZ-1R12 32K Battery Backed (via SD card) RAM Board MZ-1R18 64K RAM File board. Via JSON config file (soon to be via web config), you can decide wether to use real hardware interfaces or virtual devices. Virtual store the initial drive device in RP2350 FlashRAM for instant on. Further tests on MZ700 and then will move to the MZ80A albeit the vanilla design should work in any Z80 based computer.

Booting from the internal virtual QD drive.

picoZ80 in an MZ-700, QD and Floppy Drives fully working. QD/Tape has tight timing so Z80 CPU Cycle must be adhered to. Videos below are using internal RAM and access is synced to the Z80 host clock. QD interface is driven by an MZ-1E14 so using a virtualised MZ-1E19 ROM to enable QD usage in an MZ-700. Now to code virtual MZ-1F11/MZ-1E19/MZ-1R12/MZ-1R18 interfaces before moving onto the MZ-80A/MZ-2000.