I am building a laptop with a W65C02, lots of memory, SID-sound, decent graphics and a filesystem.
To make the experience fit your profile, pick a username and tell us what interests you.
plain - 32.79 kB - 06/03/2021 at 12:44
I've started porting Fuzix to PZ1, which is very exciting. Much of my own scheduler ideas can be used in some fashion in the Fuzix kernel, but first I need to get it running.
I happened to read the sticker under the keyboard I'm using and it actually specs the supply voltage to 3.3-5V. This means I can get rid of the level converter.
Fewer components, YAY!
This is what it looks like right now. The left-most chip on the right board is the ATF22LV10C SPLD, next to the memory. The left board is a Raspberry pi Pico that together with 4 74LVC244 buffers form a 32-bit input bank. The Pico has only 26 usable GPIO, which is not really enough for what I need. Maybe more on that in the future.
The Pico runs a very simple program that reads CLK/RW/address/data from the 65C02 and the outputs from the SPLD so I can see what goes on as I single-step the clock from the Teensy. It is very useful to have a static CPU like the 65C02 that CAN actually work at human-readable speeds!
It took far too much time to track down the problem with programming the ATF22LV10C SPLDs.
I started out with the afterburner programmer trying to get the ATF750LVC to program, but failed. The chips are seemingly not compatible enough with ATF750C.
After getting the smaller ATF22LV10C I tried using them instead. The software claimed programming and verifying worked but the chips did NOT work properly in my testbench. I spent a lot of time searching for what was wrong. In the end I succeeded when recompiling all the code for the programmer from the main branch, that lacks support for ATF750C. Oh well, it sometimes takes a long time to travel small distances.
I am very happy to finally being able to program SPLDs, it makes the project so much easier to do properly.
I've built an atfblaster/afterburner that can now program my ATF22V10 chips. WinCUPL is not the most expressive software when trying to understand what is wrong in the source, but it works under wine/linux.
My main problem now is that I created a test setup with a Pico and the 22V10 to test the function, but I can't seem to get anything to work. More debugging and trial/error to go.
I've worked on the extended HW version with Teensy, W65C02, memory and bank registers. Updated the schematic and did a 2-layer PCB layout. The auto-router didn't want to play so it was all done by hand. Lots of changes to pinning on the Teensy, bank-registers and memory to ease the routing. It was not possible to route by hand otherwise.
Now I'll wait a few days and then do a proper audit before I commit to an order from some Chinese PCB-manufacturer.
The new pinning means more CPU-cycles spent on the Teensy, but that is not a big problem. The major delays are because of the 74HC bank registers which are sooo slow! A CPLD would have been MUCH faster, AND easier to implement. Unfortunately my old programmer does not want to play...
Experimenting on a bread-board is very quick and works well. It is not very stable though, cables come loose too easily. I decided to build a stable HW-platform for my SW-development so I brought out the soldering iron.
The result is compact and stable, but I really don't like to mess with all the wire-cutting and soldering. Next version of the build, with external SRAM and bank registers, will be built on a professionally manufactured PCB.
Missing from this build is the connector to the screen, which will be a (small) build for another day.
No, not really. But I have worked more on the documentation and converted it to a plain text document, 78 characters wide in true retro fashion. Will print very nicely :D
When I rebuild the PZ1 HW, the SW has to wait for later. This was not ideal, so yesterday I built a second PZ1 that has only a Teensy and a 65C02 connected on a bread board. This platform is perfect for testing new 65C02 code, and also to test new HW ideas in a simulated environment.
Today I wrote a lot of code to test and document the instruction timings of the 65C02. Available documents disagree on many of the timings, and/or are very hard to decipher.
Now, if I could only find how to enclose the document...
EDIT: the pdf is now available under project files
EDIT2: updated the pdf
I've moved and that takes much more time than expected. Today was the first day in a very long time that I had an opportunity to play with PZ1. It took 2-3h to get back to the previous point since I had reinstalled the OS and build environment and the display library just had to have an older version installed. The latest version disrupts the sound for some reason :(
Since the move I have a slightly bigger hacking cave, even though the apartment is smaller. YAY!
I had some time to think about the future of my HW endeavours, and I've decided that until I get a proper CPLD (ATF1504) running, I won't change the current Teensy4.1 / 65C02 / 512KiB SRAM configuration.
An annoyance I have is that I cannot find proper/non-cryptic 65C02-docs with consistent cycle-timings. There are some holes and I really want to know! The good thing about my current HW setup is that it is possible to actually write test-code, single step it and count the cycles on a real 65C02. Code and docs coming up :D
Become a member to follow this project and never miss any updates